From memsvcs at arin.net Tue Apr 5 13:55:55 2005 From: memsvcs at arin.net (Member Services) Date: Tue, 5 Apr 2005 13:55:55 -0400 Subject: [ppml] Remote Participation at ARIN XV Message-ID: <20050405175603.9C9611FEDA@mercury.arin.net> In its continuing effort to supply the community with an open forum, ARIN is again offering individuals who cannot attend the ARIN XV and NAv6TF Summit in person the opportunity to participate remotely. Remote participants may post questions and comments to be addressed in normal question and answer periods throughout the agenda. This method of interactively participating in the meeting will only be available to those who have not registered to attend the meeting in person, and will be open during both the ARIN Public Policy and Members Meetings. Comments received from remote participants will be moderated and presented to the meeting during normal question and answer periods. ARIN will use e-mail to provide the interactive portion of the remote participation effort. To register for remote participation, please send an e-mail to remote at arin.net with "Remote Participation" as the subject by Sunday, April 17. ARIN will send a reply e-mail with any steps necessary to complete the registration process and instructions on how to participate remotely in the meeting. All remote participants are subject to the Remote Participation Acceptable Use Policy (AUP) available at: http://www.arin.net/ARIN-XV/remote_aup.html For additional information about the ARIN XV and NAv6TF Summit, the public webcast, and remote participation, please see the ARIN website at: http://www.arin.net/ARIN-XV/ Regards, Member Services American Registry for Internet Numbers (ARIN) From william at elan.net Sat Apr 9 13:13:57 2005 From: william at elan.net (william(at)elan.net) Date: Sat, 9 Apr 2005 10:13:57 -0700 (PDT) Subject: [ppml] Remote Participation at ARIN XV In-Reply-To: <20050405175603.9C9611FEDA@mercury.arin.net> References: <20050405175603.9C9611FEDA@mercury.arin.net> Message-ID: Not directly remote participation question, but I'd like to know if Webcast for meeting would include V6FORUM sessions or only ARIN sessions (and if V6 sessions, will it also be available for Thursday)? On Tue, 5 Apr 2005, Member Services wrote: > In its continuing effort to supply the community with an open forum, ARIN is > again offering individuals who cannot attend the ARIN XV and NAv6TF Summit > in person the opportunity to participate remotely. Remote participants may > post questions and comments to be addressed in normal question and answer > periods throughout the agenda. > > This method of interactively participating in the meeting will only be > available to those who have not registered to attend the meeting in person, > and will be open during both the ARIN Public Policy and Members Meetings. > Comments received from remote participants will be moderated and presented > to the meeting during normal question and answer periods. ARIN will use > e-mail to provide the interactive portion of the remote participation > effort. > > To register for remote participation, please send an e-mail to > remote at arin.net with "Remote Participation" as the subject by Sunday, April > 17. ARIN will send a reply e-mail with any steps necessary to complete the > registration process and instructions on how to participate remotely in the > meeting. > > All remote participants are subject to the Remote Participation Acceptable > Use Policy (AUP) available at: > > http://www.arin.net/ARIN-XV/remote_aup.html > > For additional information about the ARIN XV and NAv6TF Summit, the public > webcast, and remote participation, please see the ARIN website at: > > http://www.arin.net/ARIN-XV/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Sun Apr 10 11:46:40 2005 From: memsvcs at arin.net (Member Services) Date: Sun, 10 Apr 2005 11:46:40 -0400 Subject: [ppml] Remote Participation at ARIN XV Message-ID: <42594A60.6070406@arin.net> William, ARIN will provide a webcast of all four days, Monday through Thursday, to include the NAv6TF Summit meetings. The only portion of the Summit meeting not webcast is their Wednesday afternoon closed Members Meeting. The ARIN Members Meeting will be webcast. Regards, Member Services American Registry for Internet Numbers(ARIN) From william at elan.net Sun Apr 10 17:02:53 2005 From: william at elan.net (william(at)elan.net) Date: Sun, 10 Apr 2005 14:02:53 -0700 (PDT) Subject: [ppml] Re: Remote Participation at ARIN XV In-Reply-To: <42594A60.6070406@arin.net> References: <42594A60.6070406@arin.net> Message-ID: That's good to hear! ARIN is making great service to internet community for those interested in moving to IP6 by making V6Forum sessions available like this. You should really spread the word about this beyond just ppml, I'd not be surprised if both APNIC and RIPE region people would be interested in this too (or let nanog know too, there are many there who might be interested and do not otherwise follow arin lists). I'm assuming the webcast mpegs will also be saved and be available for future download and view as well, right? On Sun, 10 Apr 2005, Member Services wrote: > William, > > ARIN will provide a webcast of all four days, Monday through Thursday, to > include the NAv6TF Summit meetings. The only portion of the Summit meeting > not webcast is their Wednesday afternoon closed Members Meeting. The ARIN > Members Meeting will be webcast. > > Regards, > > Member Services > American Registry for Internet Numbers(ARIN) > > -- William Leibzon Elan Networks william at elan.net From memsvcs at arin.net Wed Apr 13 10:29:31 2005 From: memsvcs at arin.net (Member Services) Date: Wed, 13 Apr 2005 10:29:31 -0400 Subject: [ppml] Remote Participation Registration Reminder Message-ID: <20050413142927.6A5991FEDA@mercury.arin.net> Remote Participation Information ARIN XV Remote Participation Availability Monday, April 18 9AM - 12:30PM Public Policy Meeting Tuesday, April 19 9AM - 12:30 PM Public Policy Meeting Wednesday, April 20 9AM - 12:30 PM Public Policy Meeting 2PM - 5:30 PM Members Meeting To register for remote participation, e-mail remote at arin.net with "Remote Participation" in the subject by Sunday, April 17. ARIN will send a reply e-mail with any steps necessary to complete the registration process and instructions on how to participate remotely in the meeting. In its continuing effort to supply the community with an open forum, ARIN is again offering individuals who cannot attend the ARIN XV and NAv6TF Summit in person the opportunity to participate remotely. Remote participants may post questions and comments to be addressed in normal question and answer periods throughout the agenda. This method of interactively participating in the meeting will only be available to those who have not registered to attend the meeting in person, and will be open during both the ARIN Public Policy and Members Meetings. Comments received from remote participants will be moderated and presented to the meeting during normal question and answer periods. ARIN will use e-mail to provide the interactive portion of the remote participation effort. All remote participants are subject to the Remote Participation Acceptable Use Policy (AUP) available at: http://www.arin.net/ARIN-XV/remote_aup.html For additional information about the ARIN XV and NAv6TF Summit, the public webcast, and remote participation, please see the ARIN website at: http://www.arin.net/ARIN-XV/ Regards, Member Services American Registry for Internet Numbers (ARIN) From lea.roberts at stanford.edu Wed Apr 13 12:09:53 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Wed, 13 Apr 2005 09:09:53 -0700 (PDT) Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <20050413142927.6A5991FEDA@mercury.arin.net> Message-ID: greetings all next week we'll be discussing 2005-1 in Orlando and I have some questions since one of the good arguments for 2005-1 is to allow provider independent multi-homing, is there anyone out there who has been following the multi6 working group in IETF who believes there will a timely alternative forthcoming from that working group? do folks believe that PI /48s assigned under 2005-1, should it become policy, would be willingly returned to ARIN by assignees once an alternative workable multi6 implementation exists or would this policy just create SWAMPv6? thanks in advance for your thoughts, /Lea From andrew.dul at quark.net Wed Apr 13 12:38:06 2005 From: andrew.dul at quark.net (=?iso-8859-1?B?QW5kcmV3IER1bA==?=) Date: Wed, 13 Apr 2005 16:38:06 +0000 Subject: [ppml] 2005-1 and/or Multi6 Message-ID: <20050413163807.15077.qmail@hoster908.com> > > since one of the good arguments for 2005-1 is to allow provider > independent multi-homing, is there anyone out there who has been following > the multi6 working group in IETF who believes there will a timely > alternative forthcoming from that working group? > I was at the last IETF meeting in Minneapolis and attended the multi6 working group meeting & shim6 BOF. I honestly haven't been following this work closely but here are a few thoughts. The multi6 group has basically wrapped up their work at the Minneapolis meeting. The "multi6" work will continue with the proposed solution in the "shim6" working group which had a BOF at the meeting to finalize the working group charter. Realistically from my perspective... I don't see this protocol being standardized until 1-2 years from now. Additionally since this is a host based implementation we probably won't see this largely deployed in a majority of IPv6 stacks for another 3-5 years. I been trying to envision a shim6 world...and at this point I don't see the compelling reasons for doing multihoming this way. > do folks believe that PI /48s assigned under 2005-1, should it become > policy, would be willingly returned to ARIN by assignees once an > alternative workable multi6 implementation exists or would this policy > just create SWAMPv6? I assume that those who received the address space would not willingly return it. Interestingly I had an exchange at the microphone during the IAB Plenary open session about this topic. I pointed that this policy existing and is being considered in the ARIN region and if this policy was implemented the ideas about a very small v6 routing table may go away. Someone responded with a comment like, that is just fine for the first 65k routes. Andrew From iggy at merit.edu Wed Apr 13 12:55:29 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Wed, 13 Apr 2005 12:55:29 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <423AF7D4.9010803@arin.net> References: <423AF7D4.9010803@arin.net> Message-ID: Why? Why is this nessasary? If someone's got their in-addr.arpa stuff broken, it's not really hurting anyone but themselves. Seems like this is a waste of ARIN resources to me. Glenn On Fri, 18 Mar 2005, 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. > > 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 > > > > > > > !DSPAM:423af94625628103238693! > > > From L.Howard at stanleyassociates.com Wed Apr 13 13:33:44 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 13 Apr 2005 13:33:44 -0400 Subject: [ppml] 2005-1 and/or Multi6 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Andrew Dul > Sent: Wednesday, April 13, 2005 12:38 PM > To: ppml at arin.net > Subject: Re: [ppml] 2005-1 and/or Multi6 > > > > > > since one of the good arguments for 2005-1 is to allow provider > > independent multi-homing, is there anyone out there who has been > > following the multi6 working group in IETF who believes > there will a > > timely alternative forthcoming from that working group? > > > > I was at the last IETF meeting in Minneapolis and attended > the multi6 working group meeting & shim6 BOF. Outstanding! I wish there was more cross-over, myself included. > I assume that those who received the address space would not > willingly return it. A reasonable assumption, IMHO. > Interestingly I had an exchange at the microphone during the > IAB Plenary open session about this topic. I pointed that > this policy existing and is being considered in the ARIN > region and if this policy was implemented the ideas about a > very small v6 routing table may go away. Someone responded > with a comment like, that is just fine for the first 65k routes. Any suggestion on the four billion routes after that? What Moore's Law needs is penalties for non-compliance. Lee > > Andrew > From memsvcs at arin.net Wed Apr 13 13:40:38 2005 From: memsvcs at arin.net (Member Services) Date: Wed, 13 Apr 2005 13:40:38 -0400 Subject: [ppml] New ARIN Website Message-ID: <20050413174034.702731FEDC@mercury.arin.net> ARIN unveiled the new version of its website today. While the overall design is similar to the previous site, there have been both subtle and major changes. Some highlights include: * Expanded and revised content, especially the "Registration Services" and "About Us" sections * Former "Internet Info" section renamed "International Community" and revised * Billing-related information revised and easily accessible in new top- level "Billing" section * Former "Library" section revised and renamed "Reference" * Training and educational materials available in top-level "Education" section * Improved formatting for announcements, search engine results, and policy proposals * Design goal of creating W3C XHTML- and CSS-compliant pages Please note that overall content reorganization has caused some links to change. We have installed redirects, but you should update any existing bookmarks accordingly. For greater detail on what has changed please see the article in the current edition of ARIN Review at: http://www.arin.net/newsletter/2005_first.pdf#page=9 The ARIN website is a core part of our service to the community, and we are interested in your feedback on the new design and content. Please send any comments, suggestions, or questions to webmaster at arin.net. Regards, Member Services American Registry for Internet Numbers (ARIN) From andrew.dul at quark.net Wed Apr 13 13:58:38 2005 From: andrew.dul at quark.net (=?iso-8859-1?B?QW5kcmV3IER1bA==?=) Date: Wed, 13 Apr 2005 17:58:38 +0000 Subject: [ppml] 2005-1 and/or Multi6 Message-ID: <20050413175838.32664.qmail@hoster908.com> -------Original Message------- > From: "Howard, W. Lee" > Subject: RE: [ppml] 2005-1 and/or Multi6 > Sent: 13 Apr 2005 09:33:44 > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of Andrew Dul > > Sent: Wednesday, April 13, 2005 12:38 PM > > To: ppml at arin.net > > Subject: Re: [ppml] 2005-1 and/or Multi6 > > > > > > Interestingly I had an exchange at the microphone during the > > IAB Plenary open session about this topic. I pointed that > > this policy existing and is being considered in the ARIN > > region and if this policy was implemented the ideas about a > > very small v6 routing table may go away. Someone responded > > with a comment like, that is just fine for the first 65k routes. > > Any suggestion on the four billion routes after that? My speculation is that their comment may have been a validation of the the 1AS 1 prefix allocation methodology, given the current contraints of BGP to a 16bit ASN. But I'm just not sure, I didn't have a chance to followup. If you extrapolate the 1 prefix/AS, and generally don't change the requirements for an AS, what happens to the IPv6 route table growth curve? I anticipate the overlay of address space on the edge of the network but I don't necessarily think that that address space will be served by more than 1 AS. > > What Moore's Law needs is penalties for non-compliance. > So far that means your processor company may go out of business. :) From michel at arneill-py.sacramento.ca.us Wed Apr 13 14:05:16 2005 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 13 Apr 2005 11:05:16 -0700 Subject: [ppml] 2005-1 and/or Multi6 Message-ID: > Lea Roberts wrote: > since one of the good arguments for 2005-1 is to allow provider > independent multi-homing, is there anyone out there who has been > following the multi6 working group in IETF who believes there > will a timely alternative forthcoming from that working group? I stopped following it when I realized that no alternative would come out in a timely manner, and it was a while ago. > do folks believe that PI /48s assigned under 2005-1, should it > become policy, would be willingly returned to ARIN by assignees > once an alternative workable multi6 implementation exists I don't. From the user's prospective, no multihoming alternative will ever be as simple and straightforward as a PI block, why would one spend time and money switching to a complicated solution when one already has a simple one working fine? > or would this policy just create SWAMPv6? This policy would create SWAMPv6. SWAMPv6 will be more difficult to clean than SWAMPv4, for two reasons: a) Owners of SWAMPv6 blocks willing to release them will have to do _both_ of the following: aa) renumber ab) embrace a new technology. b) There will be no pressure to recover SWAMPv6 space as address scarcity will not be an issue. In the absolute, this is bad. That being said, it does not look that bad compared to other alternatives which include: 1. NATv6, made easier by Unique Local IPv6 Unicast Addresses [compared to NATv4: no ambiguity, which is one of the major NATv4 issues]. 2. Delay furthermore v6 deployment because of the lack of a multihoming solution. 3. MEGASWAMPv6, obtained by routing Unique Local IPv6 Unicast Addresses globally (which requires nothing but enterprises and operators to conveniently "forget" to filter them under financial pressure). In other words, instead of giving money to ARIN to obtain a 2005-1 block, enterprises would give the money to their ISP(s) to "forget" to filter the Unique Local IPv6 Unicast they announce. I have opposed swamp creation in the past, but what we are facing now is not whether we will have a swamp or not but whether the swamp will remain under ARIN control or not. Although it amounts to picking between the lesser of two evils, I support 2005-1. Michel. From paul at vix.com Wed Apr 13 14:11:59 2005 From: paul at vix.com (Paul Vixie) Date: Wed, 13 Apr 2005 18:11:59 +0000 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: Message from Glenn Wiltse of "Wed, 13 Apr 2005 12:55:29 -0400." Message-ID: <20050413181159.3B49813E3F@sa.vix.com> > Why? Why is this nessasary? If someone's got their in-addr.arpa stuff > broken, it's not really hurting anyone but themselves. Seems like this > is a waste of ARIN resources to me. i don't agree. bad or missing in-addr.arpa or ip6.arpa data hurts us all. From david.conrad at nominum.com Wed Apr 13 15:19:10 2005 From: david.conrad at nominum.com (David Conrad) Date: Wed, 13 Apr 2005 12:19:10 -0700 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <20050413181159.3B49813E3F@sa.vix.com> References: <20050413181159.3B49813E3F@sa.vix.com> Message-ID: <4182f31bac91f498861d842545efbe7f@nominum.com> On Apr 13, 2005, at 11:11 AM, Paul Vixie wrote: >> Why? Why is this nessasary? If someone's got their in-addr.arpa stuff >> broken, it's not really hurting anyone but themselves. Seems like this >> is a waste of ARIN resources to me. > i don't agree. bad or missing in-addr.arpa or ip6.arpa data hurts us > all. While I do not necessarily disagree, can you expand on why you believe lack of reverse information hurts us? Rgds, -drc From paul at vix.com Wed Apr 13 15:29:23 2005 From: paul at vix.com (Paul Vixie) Date: Wed, 13 Apr 2005 19:29:23 +0000 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: Message from David Conrad of "Wed, 13 Apr 2005 12:19:10 MST." <4182f31bac91f498861d842545efbe7f@nominum.com> Message-ID: <20050413192923.5250713E4A@sa.vix.com> > >> ... If someone's got their in-addr.arpa stuff broken, it's not > >> really hurting anyone but themselves. > > i don't agree. bad or missing in-addr.arpa or ip6.arpa data hurts > > us all. > While I do not necessarily disagree, can you expand on why you believe > lack of reverse information hurts us? first and foremost, negative caching in dns is weak on its best day and it has very few good days. there is no way to express in a dns response that a nonterminal ancestor of a qname does not exist, so if someone asks: 1.187.152.204.IN-ADDR.ARPA and the thing that doesn't exist is: 187.152.204.IN-ADDR.ARPA then there is no way to signal this ancestral nonexistence, and the client can only cache the nonexistence of the qname itself. but of course a lot of dns implementors don't cache anything, or don't cache negatives, or don't cache lameness. the result is, a lot of queries hitting the dns root servers and the IN-ADDR.ARPA servers and the .ARPA servers whenever someone's inaddr is lame or nonexistent. (since folks all over the internet *will* query for these names, the lack of support for them by any given network owner is socially irresponsible.) more to the point, the data is useful when present, and normally when it's absent it's by error or omission rather than by policy. someone whose policy is to not support inaddr lookups about their network can just put an empty zone in place. but everyone ought to have to think about their intentions, and put some kind of zone in place, and keep it from being lame, since the vast majority of people who need to do that, have no policy of secrecy. thus the net impact of arin's policy will be that more useful data is available about the internet's infrastructure. for both reasons, this is an appropriate use of arin's resources. From david.conrad at nominum.com Wed Apr 13 16:16:27 2005 From: david.conrad at nominum.com (David Conrad) Date: Wed, 13 Apr 2005 13:16:27 -0700 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: Message-ID: <93ae417b30958ce6adec4ebd9663b340@nominum.com> Hi, Speaking for myself (and as someone who at one time, long ago, participated in the multi6 working group and then stopped as the OSIfication became too much to bear): On Apr 13, 2005, at 11:05 AM, Michel Py wrote: >> since one of the good arguments for 2005-1 is to allow provider >> independent multi-homing, is there anyone out there who has been >> following the multi6 working group in IETF who believes there >> will a timely alternative forthcoming from that working group? > I stopped following it when I realized that no alternative would come > out in a timely manner, and it was a while ago. I too am somewhat skeptical that shim6 will get any sort of real deployment. >> do folks believe that PI /48s assigned under 2005-1, should it >> become policy, would be willingly returned to ARIN by assignees >> once an alternative workable multi6 implementation exists > > I don't. From the user's prospective, no multihoming alternative will > ever be as simple and straightforward as a PI block, why would one > spend > time and money switching to a complicated solution when one already has > a simple one working fine? I agree. As long as renumbering is non-transparent to the user, PI will be preferable. As long as maintenance and announce-ability of PI is viewed as cheaper than the potential cost of renumbering, people will not voluntarily return a PI allocated block. It is, of course, theoretically possible for ARIN to force a return of a PI block, but I suspect if this were actually done, ARIN's legal defense fund would need a quite significant boost. >> or would this policy just create SWAMPv6? > This policy would create SWAMPv6. Err, we already have a SWAMPv6, the question is merely how large it will become. However, I have been and continue to be of the firm believe that the RIRs have little control over any swamp as it is ISPs who make the decision whether or not a particular prefix announcement is accepted. RIRs can create conditions in which a swamp can be created, in fact 2005-1 would provide such conditions, however it is the ISPs which announce/accept unaggregated prefixes that actually create the swamp. > SWAMPv6 will be more difficult to > clean than SWAMPv4, for two reasons: > a) Owners of SWAMPv6 blocks willing to release them will have to do > _both_ of the following: aa) renumber ab) embrace a new technology. > b) There will be no pressure to recover SWAMPv6 space as address > scarcity will not be an issue. While I agree with the first, I am not so confident of the second as most people appear to be. The size of prefixes being allocated today worries me. A lot. > In the absolute, this is bad. That being said, it does not look that > bad > compared to other alternatives which include: > > 1. NATv6, made easier by Unique Local IPv6 Unicast Addresses [compared > to NATv4: no ambiguity, which is one of the major NATv4 issues]. I'm not sure why NATv6 would be considered worse than SWAMPv6. As you indicate, NATv6 will indeed become simpler due to ULAs. Given the cost of renumbering scales with the number of devices on the network, I fully expect NATv6 to eventually become the primary mechanism by which IPv6 is used. The advantage of this is that it would theoretically allow for SWAMPv6 to be drained (at least to some extent). Of course, I don't consider NAT to be inherently evil (heck, I use it every day). > 2. Delay furthermore v6 deployment because of the lack of a multihoming > solution. I don't believe v6 deployment will be significantly delayed by lack of a multihoming solution. The cost of making the transition to v6, the lack of obvious non-geek justification for making that transition, and the continued requirement to have user involvement in renumbering when changing providers are all more than sufficient to slow down v6 deployment. > 3. MEGASWAMPv6, obtained by routing Unique Local IPv6 Unicast Addresses > globally (which requires nothing but enterprises and operators to > conveniently "forget" to filter them under financial pressure). In > other > words, instead of giving money to ARIN to obtain a 2005-1 block, > enterprises would give the money to their ISP(s) to "forget" to filter > the Unique Local IPv6 Unicast they announce. I guess I'm not too worried about this as I see it paralleling to some extent people announcing randomly chosen prefixes in IPv4. Yes, it happens, but most folks know that it is simply wrong. Unless the enterprise paying their ISP to have their ULA announced is willing to run the risk of having to pay every ISP of folks to whom the enterprise wants to connect, they'll probably just get a PA block, NATv6 it to some random ULA, and be done with it. > I have opposed swamp creation in the past, but what we are facing now > is > not whether we will have a swamp or not but whether the swamp will > remain under ARIN control or not. The swamp, which I define as the unaggregated prefixes in the DFZ, is not and has never been under the control of ARIN or any of the other RIRs -- the RIRs don't generally announce prefixes. In my mind, the question is really whether or not the initial conditions for rapid growth of the swamp should be permitted in order to facilitate IPv6 deployment and acceptance. The swamp can be much larger than it used to be because of Moore's Law but there is an implicit disparity/unfairness created when the limits of router CPU/memory are reached (again). As somewhat of an aside, hopefully, if 2005-1 were to be enacted, ARIN staff would do the allocations in such a way as to increase the likelihood of aggregate-ability in the future (i.e., doing sparse allocations such that if any PI requestor needed more PI space, the second prefix allocated could be aggregated with the first). Rgds, -drc My opinions, nothing more. From dr at cluenet.de Wed Apr 13 17:56:29 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 13 Apr 2005 23:56:29 +0200 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: Message-ID: <20050413215629.GB10854@srv01.cluenet.de> On Wed, Apr 13, 2005 at 11:05:16AM -0700, Michel Py wrote: > > or would this policy just create SWAMPv6? > > This policy would create SWAMPv6. SWAMPv6 will be more difficult to > clean than SWAMPv4, for two reasons: Can anyone please define "swamp"? What does the collection of PI prefixes differ in compared to the collection of PA aggregate prefixes other than probably prefix length? "Swamp" was the organisational chaos left from the early IPv4 phase. I don't see how a /32 set aside by each RIR for /48 PI prefixes can be called "swamp" unless you define all PI users as "mud". :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Ed.Lewis at neustar.biz Wed Apr 13 18:48:32 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 13 Apr 2005 18:48:32 -0400 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <4182f31bac91f498861d842545efbe7f@nominum.com> References: <20050413181159.3B49813E3F@sa.vix.com> <4182f31bac91f498861d842545efbe7f@nominum.com> Message-ID: At 12:19 -0700 4/13/05, David Conrad wrote: >On Apr 13, 2005, at 11:11 AM, Paul Vixie wrote: >>> Why? Why is this nessasary? If someone's got their in-addr.arpa stuff >>> broken, it's not really hurting anyone but themselves. Seems like this >>> is a waste of ARIN resources to me. >> i don't agree. bad or missing in-addr.arpa or ip6.arpa data hurts us all. > >While I do not necessarily disagree, can you expand on why you believe lack of >reverse information hurts us? I see Paul has answered this, but I think that there's a non-sequiter here. The lame delegation policy is meant to trim bad referrals from an ARIN managed name server to a supposedly running server that is not. The point isn't the worthiness of the reverse map at all - the point is the health of what is there. Paul's "bad or missing" - IMHO - refers to data incorrectly stating that DNS is running on a system and/or "missing" servers, not to the presence or absence of "name servers on a network block." Incorrect referrals have induced some DNS implementations to overly burden the root servers (and others). Partly to blame is the convention of a name server, in claiming lameness, is to refer the requestor back to the root. Unwary implementations would loop forever. Wary implementations that just won't take an intermediate "no" for an answer keep pounding away too. Such observations led to the original lame delegation policy. As someone who lives and breathes DNS, I can't imagine why a network operator wouldn't have at least a stub zone for their address range mostly because it's so trivial to set up and some DNS-using applications expect there to be something. But I won't go so far as to say that the reverse map is mandatory. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From lea.roberts at stanford.edu Wed Apr 13 18:55:02 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Wed, 13 Apr 2005 15:55:02 -0700 (PDT) Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <20050413215629.GB10854@srv01.cluenet.de> Message-ID: Daniel - well, perhaps 'all PI users as "mud"' is a good characterization. what I was thinking of as I wrote SWAMPv6 is that even tho the PI prefixes would be allocated by ARIN out of a single block, they would still be individual routes. They would consume a RIB slot and not be aggregatable. You could just as easily say that SWAMPv4 was all allocated out of 192/8, but it is still a large collection of /24 routes that need to be carried throughout the DFZ. So, that's my definition of "swamp" - a collection of long-prefix, non-aggregatable routes. /Lea On Wed, 13 Apr 2005, Daniel Roesen wrote: > On Wed, Apr 13, 2005 at 11:05:16AM -0700, Michel Py wrote: > > > or would this policy just create SWAMPv6? > > > > This policy would create SWAMPv6. SWAMPv6 will be more difficult to > > clean than SWAMPv4, for two reasons: > > Can anyone please define "swamp"? What does the collection of PI > prefixes differ in compared to the collection of PA aggregate prefixes > other than probably prefix length? > > "Swamp" was the organisational chaos left from the early IPv4 phase. > I don't see how a /32 set aside by each RIR for /48 PI prefixes can be > called "swamp" unless you define all PI users as "mud". :-) > > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > From Ed.Lewis at neustar.biz Wed Apr 13 19:09:24 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 13 Apr 2005 19:09:24 -0400 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <20050413215629.GB10854@srv01.cluenet.de> References: <20050413215629.GB10854@srv01.cluenet.de> Message-ID: At 23:56 +0200 4/13/05, Daniel Roesen wrote: >On Wed, Apr 13, 2005 at 11:05:16AM -0700, Michel Py wrote: >> > or would this policy just create SWAMPv6? >> >> This policy would create SWAMPv6. SWAMPv6 will be more difficult to >> clean than SWAMPv4, for two reasons: > >Can anyone please define "swamp"? What does the collection of PI >prefixes differ in compared to the collection of PA aggregate prefixes >other than probably prefix length? Taking an amaturish stab at an answer: An "overly specific" prefix of address space that is spread across multiple RIRs. (Or maybe NIR/LIR.) E.g., 192/8 in IPv4, as opposed to say, 69/8. (OTOH, 0/0 is not a swamp because it's not specific.) Implications - for DNS, having to coordinate multiple registries information into one zone. For routing, not being able to aggregate "efficiently". For other purposes - not being able to easily determine what policies may be attacked to the space. >"Swamp" was the organisational chaos left from the early IPv4 phase. >I don't see how a /32 set aside by each RIR for /48 PI prefixes can be >called "swamp" unless you define all PI users as "mud". :-) For one example of IPv6 swamping, some IPv6 was allocated to ARIN before the emergence of LACNIC and then allocated to organizations that are now in the LACNIC region. (Uses my definition of "swamp.") -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From gih at apnic.net Wed Apr 13 19:55:52 2005 From: gih at apnic.net (Geoff Huston) Date: Thu, 14 Apr 2005 09:55:52 +1000 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: <20050413142927.6A5991FEDA@mercury.arin.net> Message-ID: <6.0.1.1.2.20050414094931.033cab10@kahuna.telstra.net> At 02:09 AM 14/04/2005, Lea Roberts wrote: >greetings all > >next week we'll be discussing 2005-1 in Orlando and I have some questions > >since one of the good arguments for 2005-1 is to allow provider >independent multi-homing, is there anyone out there who has been following >the multi6 working group in IETF who believes there will a timely >alternative forthcoming from that working group? "Timely" is the issue here. I suspect this path is not one of the order of months, and probably not in the order of a year or so. >do folks believe that PI /48s assigned under 2005-1, should it become >policy, would be willingly returned to ARIN by assignees once an >alternative workable multi6 implementation exists or would this policy >just create SWAMPv6? Interesting question. I don't think there is enough data to answer this. In one scenario where global routing slots were to be a resource that implied some for of payment, then the decision to stick with a unique routing slot, or to use an alternative technology along the lines of multi-6 would be largely an economic one where each player makes a cost benefit judgement. Geoff From gih at apnic.net Wed Apr 13 20:11:06 2005 From: gih at apnic.net (Geoff Huston) Date: Thu, 14 Apr 2005 10:11:06 +1000 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <20050413163807.15077.qmail@hoster908.com> References: <20050413163807.15077.qmail@hoster908.com> Message-ID: <6.0.1.1.2.20050414095618.03419870@kahuna.telstra.net> >Interestingly I had an exchange at the microphone during the IAB Plenary >open session about this topic. I pointed that this policy existing and is >being considered in the ARIN region and if this policy was implemented the >ideas about a very small v6 routing table may go away. Someone responded >with a comment like, that is just fine for the first 65k routes. There is no need for a 'very small' routing table - there is a need for a routing table that is viable within the parameters of the infrastructure base that makes up the network. So the objective is to support address deployment practices that match deployment models to the extent that the resultant network is one that fits efficiently into the deployed infrastructure platform. These days its reasonable to suggest that the comfort zone is greater than 10**5 entries, and probably around 10**6 entries. This is of course a little higher than the current IPv6 value of some 750 entries. The concern I hear is that in creating this collection of unaggregated /48 entries in to the routing table we have no clear idea of what mechanism we may use in the future to reclaim these entries when routing slots may be under some scarcity pressure. There is the concern that this may be an enduring legacy that would be difficult to undo. On the other hand we may be placing too much emphasis on strict provider aggregation and pressure for very small routing tables in their wake creating a different, but equally tough set of issues, such as scoped addresses, id/locator split architecture, extended protocol handshakes and shared context for session support that may in the long run prove more of an intractable scaleability problem than routing! As far as I can see part of the problem here is that routing is en evironment that has very limited feedback mechanisms for control functions. Geoff From michel at arneill-py.sacramento.ca.us Wed Apr 13 20:58:15 2005 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 13 Apr 2005 17:58:15 -0700 Subject: [ppml] 2005-1 and/or Multi6 Message-ID: >>> Lea Roberts wrote: >>> or would this policy just create SWAMPv6? >> Michel Py wrote: >> This policy would create SWAMPv6. > David Conrad wrote: > Err, we already have a SWAMPv6, I don't agree with this > The swamp, which I define as the unaggregated prefixes in the DFZ This is not the swamp, IMHO. > Daniel Roesen wrote: > Can anyone please define "swamp"? This is a slippery slope, but it is evident that we need to somehow agree on a definition of "swamp". > What does the collection of PI prefixes differ in compared to the > collection of PA aggregate prefixes other than probably prefix length? IMHO, it does not. > "Swamp" was the organisational chaos left from the early IPv4 phase. > I don't see how a /32 set aside by each RIR for /48 PI prefixes can > be called "swamp" unless you define all PI users as "mud". :-) I agree with this. We can inventory what is wrong with things that ave, rightfully or not, been associated with the swamp [non exhaustive]. 1. Due to conservative allocation policies, several organizations have been allocated multiple non-aggregatable prefixes, which inflates the global routing table. IPv6 should be immune to this. 2. Early adopters have been given a PI prefix when they did not really need it. This is insignificant. 3. The prefix database is not up-to-date. 4. Prefixes have been given away for ever, not "rented" nor "leased". 5. Random prefixes. The situation as of today is one out of 4 things: a. The registered owner of the prefix announces the prefix. No problem. b. Someone else than the legitimate owner of the prefix announces it: ba. For legitimate reasons, such as the company was bought, merged, split, renamed, moved, etc. and nobody updated the paperwork. bb. For illegitimate reasons: the original owner has long disappeared and someone else hijacked the prefix, and they will try to BS ARIN that they are in the ba. situation and get it transfered. This is called prefix hijacking. c. The prefix is not allocated to anybody but someone annouces it. This is called a bogon. Although I agree that there are not too many things that can be done, bb. and c. are not long-term solutions and are good choices for short-term operations such as spamming but not a legitimate business. In the case of bb., history has demonstrated multiple times that the stuff will hit the fan sooner or later and in the case of c. a RIR will allocate that prefix to someone else sooner or later, leading in both cases to the prefix being reclaimed for legitimate use. In the case of IPv6, we are introducing a 5th possibility, which is the announcement of a random, statistically unique local IPv6 address. There is nothing ARIN can do to allocate it to someone else. Besides, contacting the concerned organization might prove difficult as it does not even need to be registered. This can't happen with IPv4 because local addresses are ambiguous: try to announce 192.168.1.0/24 :-D Even though we might occasionally see RFC1918 prefixes in the global table, nobody would think about doing this to build a business so there is no problem. With local addresses being unique in v6, this becomes a problem. IMHO, the IPv6 swamp would be a combination of 3. 4. and 5. above. Why? 3. It's not because they're using IPv6 that bums are going to update the database entries when they did not do it for v4. 4. Even if with v6 prefixes are not given away for life but "rented" or "leased", the bottom line is that it costs a lot less to leave things "as-is" vs. actively reclaiming the prefix of people that have stopped paying, for example. Given the lack of pressure to reclaim these prefixes because of address space scarcity, and although in _theory_ RIRs could indeed reclaim prefixes, what is going to happen in many cases is that once a prefix has been allocated to someone on a termed basis the reality will kick in and make it lifelong for most cases. 5. As explained above, the reason people don't try to announce RFC1918 prefixes is because it does not work, not because we say they should not. And here we have our swamp. >> Michel Py wrote: >> SWAMPv6 will be more difficult to clean than SWAMPv4, for two reasons: >> a) Owners of SWAMPv6 blocks willing to release them will have to do >> _both_ of the following: aa) renumber ab) embrace a new technology. >> b) There will be no pressure to recover SWAMPv6 space as address >> scarcity will not be an issue. > David Conrad wrote: > While I agree with the first, I am not so confident of the second > as most people appear to be. The size of prefixes being allocated > today worries me. A lot. Get used to it. This is the way out of item 1. above. > I'm not sure why NATv6 would be considered worse than SWAMPv6. Where is Keith Moore when we need him? > As you indicate, NATv6 will indeed become simpler due to ULAs. Given > the cost of renumbering scales with the number of devices on the > network, I fully expect NATv6 to eventually become the primary > mechanism by which IPv6 is used. Let's say one of the primary mechanisms. > The advantage of this is that it would theoretically > allow for SWAMPv6 to be drained (at least to some extent). I don't think so. The bulk of NATv6 users will have a PA prefix just as they do today and it won't change much the size of the routing table. >> 3. MEGASWAMPv6, obtained by routing Unique Local IPv6 Unicast >> Addresses globally (which requires nothing but enterprises and >> operators to conveniently "forget" to filter them under financial >> pressure). In other words, instead of giving money to ARIN to >> obtain a 2005-1 block, enterprises would give the money to their >> ISP(s) to "forget" to filter the Unique Local IPv6 Unicast they >> announce. > I guess I'm not too worried about this as I see it paralleling to > some extent people announcing randomly chosen prefixes in IPv4. > Yes, it happens, but most folks know that it is simply wrong. Downloading pirated .mp3 is wrong too, and there must be a hundred million users that are doing it right now. > Unless the enterprise paying their ISP to have their ULA > announced is willing to run the risk of having to pay every > ISP of folks to whom the enterprise wants to connect, Impossible, but not required because all of the other ISPs would be under pressure from _their_ customers not to filter ULAs. There is a critical mass that needs to be reached, but if it is reached it will trigger a chain reaction. Remember, this costs nothing to the ISP. > they'll probably just get a PA block, NATv6 it to > some random ULA, and be done with it. You are making my point above. I will point out though that NATv6 on a PI block is better than NATv6 on a PA block. > The swamp, which I define as the unaggregated prefixes in the > DFZ, is not and has never been under the control of ARIN or > any of the other RIRs This is where the control thing comes in: with v4, there are things RIRs can do when people anounce hijacked prefixes or bogons. With v6, there is nothing the RIRs can do if people anounce ULAs. This is what I call losing control. > As somewhat of an aside, hopefully, if 2005-1 were to be > enacted, ARIN staff would do the allocations in such a way > as to increase the likelihood of aggregate-ability in the > future (i.e., doing sparse allocations such that if any PI > requestor needed more PI space, the second prefix allocated > could be aggregated with the first). There is no reason to believe that ARIN would not do this as there is a documented way (RFC3531), but again the best way to avoid it is to allocate short enough prefixes so the requester never comes back for more. The number of entries in the routing table is a constrained resource, not IPv6 address space. If lowering the first means wasting the second, be it. Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed Apr 13 22:05:26 2005 From: randy at psg.com (Randy Bush) Date: Wed, 13 Apr 2005 22:05:26 -0400 Subject: [ppml] 2005-1 and/or Multi6 References: <20050413142927.6A5991FEDA@mercury.arin.net> <6.0.1.1.2.20050414094931.033cab10@kahuna.telstra.net> Message-ID: <16989.53222.624503.284218@roam.psg.com> >> do folks believe that PI /48s assigned under 2005-1, should it become >> policy, would be willingly returned to ARIN by assignees once an >> alternative workable multi6 implementation exists or would this policy >> just create SWAMPv6? > Interesting question. I don't think there is enough data to answer > this. In one scenario where global routing slots were to be a resource > that implied some for of payment, then the decision to stick with a unique > routing slot, or to use an alternative technology along the lines of > multi-6 would be largely an economic one where each player makes a cost > benefit judgement. and, in the absense of serious incentive, should we not look to history. how much v4 swamp space has been returned? and i know just the aussies who could answer this with a pretty picture. :-) randy From gih at apnic.net Wed Apr 13 22:31:37 2005 From: gih at apnic.net (Geoff Huston) Date: Thu, 14 Apr 2005 12:31:37 +1000 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <16989.53222.624503.284218@roam.psg.com> References: <20050413142927.6A5991FEDA@mercury.arin.net> <6.0.1.1.2.20050414094931.033cab10@kahuna.telstra.net> <16989.53222.624503.284218@roam.psg.com> Message-ID: <6.0.1.1.2.20050414123012.034080c0@kahuna.telstra.net> At 12:05 PM 14/04/2005, Randy Bush wrote: > >> do folks believe that PI /48s assigned under 2005-1, should it become > >> policy, would be willingly returned to ARIN by assignees once an > >> alternative workable multi6 implementation exists or would this policy > >> just create SWAMPv6? > > Interesting question. I don't think there is enough data to answer > > this. In one scenario where global routing slots were to be a resource > > that implied some for of payment, then the decision to stick with a unique > > routing slot, or to use an alternative technology along the lines of > > multi-6 would be largely an economic one where each player makes a cost > > benefit judgement. > >and, in the absense of serious incentive, should we not look to >history. how much v4 swamp space has been returned? and i know >just the aussies who could answer this with a pretty picture. :-) Fair enough - I'll see what can be done in terms of dredging the IPv4 swamp space to look at what happened there over time. Geoff From Suzanne_Woolf at isc.org Thu Apr 14 00:27:30 2005 From: Suzanne_Woolf at isc.org (Suzanne Woolf) Date: Thu, 14 Apr 2005 04:27:30 +0000 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <6.0.1.1.2.20050414123012.034080c0@kahuna.telstra.net> References: <20050413142927.6A5991FEDA@mercury.arin.net> <6.0.1.1.2.20050414094931.033cab10@kahuna.telstra.net> <16989.53222.624503.284218@roam.psg.com> <6.0.1.1.2.20050414123012.034080c0@kahuna.telstra.net> Message-ID: <20050414042730.GA37167@farside.isc.org> On Thu, Apr 14, 2005 at 12:31:37PM +1000, Geoff Huston wrote: > >and, in the absense of serious incentive, should we not look to > >history. how much v4 swamp space has been returned? and i know > >just the aussies who could answer this with a pretty picture. :-) > > Fair enough - I'll see what can be done in terms of dredging the IPv4 swamp > space to look at what happened there over time. Would love to know, but I have a sad suspicion it's not gotten any easier to get definitive answers about what's going on with the IPv4 swamp space over the last nine (!) years. i.e. it's easy to tell what's announced, but not so easy to tell what someone thinks is or was "theirs". http://www.academ.com/nanog/feb1996/pier.ip.address.survey.html From michel at arneill-py.sacramento.ca.us Thu Apr 14 01:04:56 2005 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 13 Apr 2005 22:04:56 -0700 Subject: [ppml] 2005-1 and/or Multi6 Message-ID: > Daniel Roesen wrote: > Can anyone please define "swamp"? A cut-and-paste casualty lost the following point about semantics in my previous post: No matter what the definition of "IPv4 swamp" is, "IPv6 swamp" can't be the same. For example, many would agree that "IPv4 swamp" (whatever it means) is pre-CIDR, when IPv6 is CIDR to begin with and therefore they can't be compared. To this effect, "IPv6 swamp" might mean "let's not do mistakes similar to the ones we did with v4 again". Michel. From owen at delong.com Thu Apr 14 02:49:21 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Apr 2005 23:49:21 -0700 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <93ae417b30958ce6adec4ebd9663b340@nominum.com> References: <93ae417b30958ce6adec4ebd9663b340@nominum.com> Message-ID: <2147483647.1113436160@[172.17.1.152]> > As somewhat of an aside, hopefully, if 2005-1 were to be enacted, ARIN > staff would do the allocations in such a way as to increase the > likelihood of aggregate-ability in the future (i.e., doing sparse > allocations such that if any PI requestor needed more PI space, the > second prefix allocated could be aggregated with the first). This is not an aside. This is addressed in the proposed policy. The policy draft states: If the organization grows to require more space, it will not be entitled to an additional block, but rather may obtain a new, replacement block of sufficient size to meet its needs in exchange for making the commitment to return its existing block within 24 months, so that it may be reassigned. Thus, no need for sparse allocation, as, larger allocation requires a renumber to the larger allocation. Only one allocation per AS under this policy, except for 24 month transition period where maximum of 2 allocations is possible. 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 owen at delong.com Thu Apr 14 03:12:07 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Apr 2005 00:12:07 -0700 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: Message-ID: <2147483647.1113437527@[172.17.1.152]> Actually, there are parts of swapmv4 in 192, 193, 194, and, arguably, some of the old B addresses which often appear in deaggregated (subnet) form. 2005-1 would not do this. It would be very easy for providers to render the v6 swamp and this policy moot simply by refusing to advertise routes within the designated block. My intent is to propose a policy that is slightly less evil than what will happen without it. I have no delusions that a swamp is a good thing. I do think that PI addressing is necessary as long as v6 does not solve the real problem. The real problem, however, is not apropos to ARIN. In short, it is the need to separate the interdomain routing tag from the end system identifiers. Owen --On Wednesday, April 13, 2005 15:55 -0700 Lea Roberts wrote: > Daniel - > > well, perhaps 'all PI users as "mud"' is a good characterization. > > what I was thinking of as I wrote SWAMPv6 is that even tho the PI prefixes > would be allocated by ARIN out of a single block, they would still be > individual routes. They would consume a RIB slot and not be aggregatable. > You could just as easily say that SWAMPv4 was all allocated out of 192/8, > but it is still a large collection of /24 routes that need to be carried > throughout the DFZ. So, that's my definition of "swamp" - a collection of > long-prefix, non-aggregatable routes. /Lea > > On Wed, 13 Apr 2005, Daniel Roesen wrote: > >> On Wed, Apr 13, 2005 at 11:05:16AM -0700, Michel Py wrote: >> > > or would this policy just create SWAMPv6? >> > >> > This policy would create SWAMPv6. SWAMPv6 will be more difficult to >> > clean than SWAMPv4, for two reasons: >> >> Can anyone please define "swamp"? What does the collection of PI >> prefixes differ in compared to the collection of PA aggregate prefixes >> other than probably prefix length? >> >> "Swamp" was the organisational chaos left from the early IPv4 phase. >> I don't see how a /32 set aside by each RIR for /48 PI prefixes can be >> called "swamp" unless you define all PI users as "mud". :-) >> >> >> Best regards, >> Daniel >> >> -- >> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 >> > -- 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 owen at delong.com Thu Apr 14 03:18:34 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Apr 2005 00:18:34 -0700 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <6.0.1.1.2.20050414095618.03419870@kahuna.telstra.net> References: <20050413163807.15077.qmail@hoster908.com> <6.0.1.1.2.20050414095618.03419870@kahuna.telstra.net> Message-ID: <2147483647.1113437913@[172.17.1.152]> The mechanism for reclamation would be as follows: 1. Either: ARIN Board makes emergency decision to stop issuing space under this policy, and, no space under this policy is eligible for renewal. or ARIN policy process determines an end of life procedure for this policy. 2. After 1, the inability to perform annual renewal eliminates the existing resource assignments through attrition. Owen --On Thursday, April 14, 2005 10:11 +1000 Geoff Huston wrote: > >> Interestingly I had an exchange at the microphone during the IAB Plenary >> open session about this topic. I pointed that this policy existing and >> is being considered in the ARIN region and if this policy was >> implemented the ideas about a very small v6 routing table may go away. >> Someone responded with a comment like, that is just fine for the first >> 65k routes. > > There is no need for a 'very small' routing table - there is a need for a > routing table that is viable within the parameters of the infrastructure > base that makes up the network. So the objective is to support address > deployment practices that match deployment models to the extent that the > resultant network is one that fits efficiently into the deployed > infrastructure platform. These days its reasonable to suggest that the > comfort zone is greater than 10**5 entries, and probably around 10**6 > entries. This is of course a little higher than the current IPv6 value of > some 750 entries. The concern I hear is that in creating this collection > of unaggregated /48 entries in to the routing table we have no clear idea > of what mechanism we may use in the future to reclaim these entries when > routing slots may be under some scarcity pressure. There is the concern > that this may be an enduring legacy that would be difficult to undo. On > the other hand we may be placing too much emphasis on strict provider > aggregation and pressure for very small routing tables in their wake > creating a different, but equally tough set of issues, such as scoped > addresses, id/locator split architecture, extended protocol handshakes > and shared context for session support that may in the long run prove > more of an intractable scaleability problem than routing! > > As far as I can see part of the problem here is that routing is en > evironment that has very limited feedback mechanisms for control > functions. > > Geoff > > > > -- 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 owen at delong.com Thu Apr 14 03:22:12 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Apr 2005 00:22:12 -0700 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <16989.53222.624503.284218@roam.psg.com> References: <20050413142927.6A5991FEDA@mercury.arin.net> <6.0.1.1.2.20050414094931.033cab10@kahuna.telstra.net> <16989.53222.624503.284218@roam.psg.com> Message-ID: <2147483647.1113438131@[172.17.1.152]> > > and, in the absence of serious incentive, should we not look to > history. how much v4 swamp space has been returned? and i know > just the aussies who could answer this with a pretty picture. :-) Virtually nothing allows ARIN to have any leg to stand on for reclaiming the majority of SwampV4 space. V6, once the policy is changed to no longer allow annual renewal of 2005-1 issued space, there are no more renewals, and, the space is reclaimed through attrition in 1-2 years. 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 gih at apnic.net Thu Apr 14 05:27:39 2005 From: gih at apnic.net (Geoff Huston) Date: Thu, 14 Apr 2005 19:27:39 +1000 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <20050414042730.GA37167@farside.isc.org> References: <20050413142927.6A5991FEDA@mercury.arin.net> <6.0.1.1.2.20050414094931.033cab10@kahuna.telstra.net> <16989.53222.624503.284218@roam.psg.com> <6.0.1.1.2.20050414123012.034080c0@kahuna.telstra.net> <20050414042730.GA37167@farside.isc.org> Message-ID: <6.0.1.1.2.20050414192626.033c7680@kahuna.telstra.net> At 02:27 PM 14/04/2005, Suzanne Woolf wrote: >On Thu, Apr 14, 2005 at 12:31:37PM +1000, Geoff Huston wrote: > > >and, in the absense of serious incentive, should we not look to > > >history. how much v4 swamp space has been returned? and i know > > >just the aussies who could answer this with a pretty picture. :-) > > > > Fair enough - I'll see what can be done in terms of dredging the IPv4 > swamp > > space to look at what happened there over time. > >Would love to know, but I have a sad suspicion it's not gotten any >easier to get definitive answers about what's going on with the IPv4 >swamp space over the last nine (!) years. I've noticed that old AS nums and old address blocks just fade away from the routing table, and the routing swamp may well just be evaporating away :-) Geoff From kurtis at kurtis.pp.se Thu Apr 14 05:45:04 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 14 Apr 2005 11:45:04 +0200 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <20050413175838.32664.qmail@hoster908.com> References: <20050413175838.32664.qmail@hoster908.com> Message-ID: <0d14594902e70f684f68519b00b24559@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-04-13, at 19.58, Andrew Dul wrote: >> Any suggestion on the four billion routes after that? > > My speculation is that their comment may have been a validation of the > the 1AS 1 prefix allocation methodology, given the current contraints > of BGP to a 16bit ASN. But I'm just not sure, I didn't have a chance > to followup. > > If you extrapolate the 1 prefix/AS, and generally don't change the > requirements for an AS, what happens to the IPv6 route table growth > curve? > > I anticipate the overlay of address space on the edge of the network > but I don't necessarily think that that address space will be served > by more than 1 AS. Current predictions for what it's worth is that we will run out of AS:es before IPv4 space... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQl47qqarNKXTPFCVEQL1nQCfbztImAQstPHcW5FrpKxot3y7R3IAn2mS 6VB0o2Qyd8hW65kHK8U0Wwyr =rPLj -----END PGP SIGNATURE----- From Michael.Dillon at radianz.com Thu Apr 14 06:20:04 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 14 Apr 2005 11:20:04 +0100 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: Message-ID: > since one of the good arguments for 2005-1 is to allow provider > independent multi-homing, is there anyone out there who has been following > the multi6 working group in IETF who believes there will a timely > alternative forthcoming from that working group? I don't believe that multi6 will be done anytime soon. > do folks believe that PI /48s assigned under 2005-1, should it become > policy, would be willingly returned to ARIN by assignees once an > alternative workable multi6 implementation exists or would this policy > just create SWAMPv6? I don't believe that ARIN should be allocating anybody IPv6 ranges that are smaller than a /32. However, I see no reason why ARIN should not hand out an IPv6 /32 block to any AS number holder who asks for one, no questions asked. First, an IPv6 /32 is the same percentage of the total address space as an IPv4 /32. So I don't view this as being wasteful in any way. Second, an AS number holder has already met some qualifications to get the AS number and I think that should be sufficient to also get an IPv6 /32. And most importantly, I think it would be BAD precedent for ARIN to encourage the insertion of LONG prefixes in the global IPv6 routing table. Router manufacturers have some options to optimize their implementations if all PI prefixes are 32 bits or less. If we start issuing lots of /48s then we steal away that opportunity for optimizing the router hardware. That would be bad. --Michael Dillon From Michael.Dillon at radianz.com Thu Apr 14 06:35:27 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 14 Apr 2005 11:35:27 +0100 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <20050413215629.GB10854@srv01.cluenet.de> Message-ID: > Can anyone please define "swamp"? What does the collection of PI > prefixes differ in compared to the collection of PA aggregate prefixes > other than probably prefix length? My definition of "swamp" is an IP address range in which many LONG prefixes (small blocks) are allocated for us in a provider independent (PI) manner with little to no possibility of aggregating those prefixes into shorter ones. In IPv6, this is bad because it means that more bits will have to be consumed by the global routing table, communicated in BGP announcements, and processed in routing calculations. I do not believe that we will see the same improvements in memory capacity, processor power, and circuit capacity that we saw in IPv4's heyday because we are now approaching real physical limits to such improvement. At the same time, IPv6 increases the average prefix length even if /32 is the longest prefix to be announced. Injecting many /48 prefixes gives another 50% increase in prefix length and this all comes at a time when more and more so-called end sites are moving towards PI addresses and multihoming. We have to allocate PI addresses to these so-called end-sites because to do otherwise is restraint of trade. However, it is unwise and imprudent to offer them /48 prefixes which are highly wasteful of global router capacity when we could give them shorter /32 prefixes. In doing so we are leveraging the vast oversupply of IPv6 address space to help conserve the processor, memory, and circuit capacity of network operators. --Michael Dillon P.S. I say "so-called" end sites because I believe that it is untrue to view the Internet as something which has a center and edges where the edges are populated by end-sites. Those so-called end-sites are often internetworks in their own right. From dr at cluenet.de Thu Apr 14 07:14:13 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 14 Apr 2005 13:14:13 +0200 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: <20050413215629.GB10854@srv01.cluenet.de> Message-ID: <20050414111413.GA32095@srv01.cluenet.de> On Thu, Apr 14, 2005 at 11:35:27AM +0100, Michael.Dillon at radianz.com wrote: > > Can anyone please define "swamp"? What does the collection of PI > > prefixes differ in compared to the collection of PA aggregate prefixes > > other than probably prefix length? > > My definition of "swamp" is an IP address range in which > many LONG prefixes (small blocks) are allocated for us in > a provider independent (PI) manner with little to no > possibility of aggregating those prefixes into shorter > ones. Which is no difference to the collection of PA aggregates. You can't aggregate them anymore too. > In IPv6, this is bad because it means that more bits > will have to be consumed by the global routing table, > communicated in BGP announcements, and processed in > routing calculations. I don't think this assertion is accurate. Protocols carry IP addresses in fixed-length fields. An IPv6 prefix will always take 128 bits. Please don't go back to pre-CIDR, really. > I do not believe that we will see the same improvements > in memory capacity, processor power, and circuit > capacity that we saw in IPv4's heyday because we are > now approaching real physical limits to such improvement. Oh? Any scientific reference to that? I can remember modem manufacturers saying that when 2400bps modems were state of the art. > At the same time, IPv6 increases the average prefix length > even if /32 is the longest prefix to be announced. Who cares? > We have to allocate PI addresses to these so-called > end-sites because to do otherwise is restraint of trade. Agreed. > However, it is unwise and imprudent to offer them /48 > prefixes which are highly wasteful of global router capacity > when we could give them shorter /32 prefixes. That makes no sense. I don't see any wastage of "global router capacity". Prefix length doesn't matter to CIDR routers, unless they contain ill-advised optimizations. The only optimization I could accept is on the /64 boundary. > P.S. I say "so-called" end sites because I believe that it > is untrue to view the Internet as something which has a center > and edges where the edges are populated by end-sites. Those > so-called end-sites are often internetworks in their own right. I couldn't agree more. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Michael.Dillon at radianz.com Thu Apr 14 09:27:59 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 14 Apr 2005 14:27:59 +0100 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <20050414111413.GA32095@srv01.cluenet.de> Message-ID: > > In IPv6, this is bad because it means that more bits > > will have to be consumed by the global routing table, > > communicated in BGP announcements, and processed in > > routing calculations. > > I don't think this assertion is accurate. Protocols carry IP addresses > in fixed-length fields. An IPv6 prefix will always take 128 bits. I don't whether or not BGP can reduce the number of bits in its communications when the prefixes are shorter, however, if the number of bits communicated between peers becomes an issue, then the protocol could evolve to be more efficient in its use of bandwidth. The only place where IP addresses need to be in fixed length fields is in the IP packet headers. I am not referring to packet headers here, but to the data transmitted by the protocol. Also, I don't believe that the current details of BGP are relevant to the policy. BGP is software and it can evolve very quickly if it needs to. Physics is the ultimate in hardware and does not evolve at all. > Please don't go back to pre-CIDR, really. Even if we defined IPv6 to have three classes of address, Class X = /32, Class Y = /48 and Class Z = /64, it is still not the same as pre-CIDR. The number of possible entries in each of these classes makes it fundamentally different from the classful IPv4 addressing scheme. And I am definitely NOT proposing classful IPv6. Some ISPs already have prefixes shorter than /32 and the ability to announce a single shorter aggregate prefix is a GOOD THING. > Oh? Any scientific reference to that? Here is one scientific paper http://www.intel.com/research/documents/Bourianoff-Proc-IEEE-Limits.pdf However, if you follow the press that covers semiconductor physics and related areas, then you will find many more references to these things. Fundamentally, the boom in computing and telecommunications was fueled by the ability to make complex electronic circuits smaller by reducing the size of the wires and components. However, our physical world is composed of things called molecules, and you cannot make wires thinner than one molecule. In fact, you probably can't even make them that thin. This is a hard limit and we are beginning to approach that limit. Now scientists may indeed be able to get closer to the limit than many now believe. But at some point, this kind of smaller-cheaper-better-faster breaks down because it gets harder and harder to advance. When the result becomes smaller-pricier-better-faster, then the policies that worked during the cheaper era, cease to work. > I can remember modem manufacturers saying that when 2400bps modems > were state of the art. Good example. Modems got faster and faster and then, at 56kbps, development hist a brick wall. Today, there are no modems faster than 56kbps because the laws of physics come to play. > Who cares? The people who design and build routers and the people who pay for those routers. --Michael Dillon P.S. the state of the art in nanowire molecular electronics can be glimpsed here: http://www.hpl.hp.com/research/papers/2003/molecular_switch.pdf From dr at cluenet.de Thu Apr 14 09:58:18 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 14 Apr 2005 15:58:18 +0200 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: <20050414111413.GA32095@srv01.cluenet.de> Message-ID: <20050414135818.GA1099@srv01.cluenet.de> On Thu, Apr 14, 2005 at 02:27:59PM +0100, Michael.Dillon at radianz.com wrote: > I don't whether or not BGP can reduce the number of bits in its > communications when the prefixes are shorter, however, if > the number of bits communicated between peers becomes an > issue, then the protocol could evolve to be more efficient > in its use of bandwidth. The only place where IP addresses > need to be in fixed length fields is in the IP packet headers. > I am not referring to packet headers here, but to the data > transmitted by the protocol. ACK. But then we'd need BGP5. Question is, wether we shouldn't THEN actually move to a new model which really seperates identity and locator _from_the_beginning_ and not crammed over IP/TCP/... > Also, I don't believe that the current details of BGP are > relevant to the policy. BGP is software and it can evolve > very quickly if it needs to. I tend to agree. > Physics is the ultimate in hardware and does not evolve at all. But knowledge about physics does. > > Please don't go back to pre-CIDR, really. > > Even if we defined IPv6 to have three classes of address, > Class X = /32, Class Y = /48 and Class Z = /64, it is still > not the same as pre-CIDR. The number of possible entries in > each of these classes makes it fundamentally different from > the classful IPv4 addressing scheme. We do have that _almost_. We have "link" (/64) and "site" (/48), and ISP (/32 by default). > And I am definitely NOT proposing classful IPv6. Some ISPs > already have prefixes shorter than /32 and the ability to > announce a single shorter aggregate prefix is a GOOD THING. OK. But if you agree that CIDR is still favorable, you cannot optimize for certain "magic" prefix lengths at the same time. Don't forget that the most optimization is probably (vendors may correct me here) desirable in the longest-match algo used to determine forwarding decision. You cannot optimize there for /32, as WITHIN your AS, all forwarding decisions follow IBGP more-specifics anyway... which are really arbitrary length between your aggregate length and /64. > > Oh? Any scientific reference to that? > > Here is one scientific paper > http://www.intel.com/research/documents/Bourianoff-Proc-IEEE-Limits.pdf Thanks, will look into this. Hope I'll be able to derrive the average computing power of routing engines in 2015 from that. Or even the absolute upper limit. :-) > > I can remember modem manufacturers saying that when 2400bps modems > > were state of the art. > > Good example. Modems got faster and faster and then, at 56kbps, > development hist a brick wall. An economic one, yeah. ISDN, then DSL. Faster and cheaper. And bandwidth on POTS was fixed. Computing power isn't. > > Who cares? > > The people who design and build routers and the people who > pay for those routers. I haven't seen any vendor rep warning about PI yet. My conclusion is that they are confident to be able to build what we need. Guys, we're talking about a couple 10k prefixes for the forseeable future, at best. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From tvest at pch.net Thu Apr 14 10:16:01 2005 From: tvest at pch.net (Tom Vest) Date: Thu, 14 Apr 2005 10:16:01 -0400 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <6.0.1.1.2.20050414192626.033c7680@kahuna.telstra.net> References: <20050413142927.6A5991FEDA@mercury.arin.net> <6.0.1.1.2.20050414094931.033cab10@kahuna.telstra.net> <16989.53222.624503.284218@roam.psg.com> <6.0.1.1.2.20050414123012.034080c0@kahuna.telstra.net> <20050414042730.GA37167@farside.isc.org> <6.0.1.1.2.20050414192626.033c7680@kahuna.telstra.net> Message-ID: <389db85804e67fde3cf8ef8925d02abb@pch.net> On Apr 14, 2005, at 5:27 AM, Geoff Huston wrote: > At 02:27 PM 14/04/2005, Suzanne Woolf wrote: >> On Thu, Apr 14, 2005 at 12:31:37PM +1000, Geoff Huston wrote: >> > >and, in the absense of serious incentive, should we not look to >> > >history. how much v4 swamp space has been returned? and i know >> > >just the aussies who could answer this with a pretty picture. :-) >> > >> > Fair enough - I'll see what can be done in terms of dredging the >> IPv4 swamp >> > space to look at what happened there over time. >> >> Would love to know, but I have a sad suspicion it's not gotten any >> easier to get definitive answers about what's going on with the IPv4 >> swamp space over the last nine (!) years. > > I've noticed that old AS nums and old address blocks just fade away > from the routing table, and the routing swamp may well just be > evaporating away :-) > > Geoff I did a Gantt chart of ASN "life cycles" a while back. As of 1 May 2003, about 1628 of the (2,958 total) ASNs that were routed in late 1997 continued to be consistently present in the routing table, with "consistent" meaning visible in Route Views or NLANR data on the first of every month in between. Another 188 or so were intermittently visible, but apparently still around. Will post the picture (sadly not so pretty as Aussie output) in http://www.pch.net/resources/papers/ later today... Tom From michel at arneill-py.sacramento.ca.us Thu Apr 14 10:56:49 2005 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 14 Apr 2005 07:56:49 -0700 Subject: [ppml] 2005-1 and/or Multi6 Message-ID: > Michael Dillon wrote: > However, it is unwise and imprudent to offer them /48 prefixes > which are highly wasteful of global router capacity when we > could give them shorter /32 prefixes. In doing so we are > leveraging the vast oversupply of IPv6 address space to help > conserve the processor, memory, and circuit capacity of network > operators. Michael, I think this can't be won for the moment. The bit count issue with /48 is not the choke point of large numbers of PI prefixes. This is a matter of stability, not memory. > Daniel Roesen wrote: > I haven't seen any vendor rep warning about PI yet. > My conclusion is that they are confident to be able > to build what we need. Actually, I was discussing this privately with someone from vendor J recently, they have warned publicly for a while that they are not sure that they will be able to ride Moore's law. This was presented in May 2003: http://arneill-py.sacramento.ca.us/ipv6mh/IPv6%20Transition.ppt#888,37,P ossible Solution #1: Do Nothing or go to slide 37 of http://arneill-py.sacramento.ca.us/ipv6mh/IPv6%20Transition.ppt [slow server....] Michel From Ed.Lewis at neustar.biz Thu Apr 14 11:12:13 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 14 Apr 2005 11:12:13 -0400 Subject: [ppml] comments on 2005-2 Message-ID: http://www.arin.net/policy/proposals/2005_2.html # 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. Is "suspended" defined elsewhere? I searched the policy guide and don't see the word. # 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. "Offenders" - this seems to be an inappropriate label. There is no definition of the "offense." # 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. It would seem to me that ARIN never should respond to third party reports in the spirit of confidentiality. There is no need to have the policy to allow for ignoring "crying wolf." The worst that could happen is that if org A repeatedly says org B is "down" and ARIN either takes no steps to fix this OR is unable to fix this, org A might go to NANOG and whine. (That'll happen anyway.) I suggest dropping that paragraph. # 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 want so see IRIS on this list. The definition of IRIS for address registries has been lagging, I'd like to see it get pushed through the IETF and then deployed. With it, better authorization policies can be implemented - regarding what data is widely public and what data is available only to the registrant, etc. (If IRIS isn't beneficial, I'd like to know why.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Thu Apr 14 11:17:45 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 14 Apr 2005 11:17:45 -0400 Subject: [ppml] comments on 2004-8 Message-ID: http://www.arin.net/policy/proposals/2004_8.html # 4. Announcement of IANA allocations to the RIRs # # When address space is allocated to a RIR, the IANA will send a detailed # announcement to the receiving RIR. The IANA will also make announcements # to all other RIRs, informing them of the recent allocation. The RIRs will # coordinate announcements to their respective membership lists and any other # lists they deem necessary. This issue came up in discussing a similar policy for IPv4 by ICANN's gTLD constituency: # The suggestion relates to the second sentence of the first paragraph of # Section 4:"The IANA will also make announcements to all other RIRs, # informing them of the recent allocation." So, I'd suggest adding a sentence stating that "IANA will also announce the allocation to other interested parties." This is something that IANA ought to do, not the RIR's. The RIR's don't have the relationships with gTLDs, ccTLDs, etc., etc., that IANA has. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Thu Apr 14 11:25:45 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 14 Apr 2005 11:25:45 -0400 Subject: [ppml] comments on 2004-3 Message-ID: http://www.arin.net/policy/proposals/2004_3.html # End-users not currently connected to an ISP and/or not planning to be # connected to the Internet are encouraged to use private IP address numbers # reserved for non-connected networks (see RFC 1918). When private, # non-connected networks require interconnectivity and the private IP address # numbers are ineffective, globally unique addresses may be requested and # used to provide this interconnectivity. I would like to add that these registrations are barred from listing name servers. If these networks are truly "not...connected to the Internet" then there is no reason to list name servers for these networks in the Internet-viewable DNS and APID (ARIN Public Information Database). There would be no reason for the registrant to operate name servers on the public Internet for these unreachable destinations. Without barring name servers on these networks, there is potential for lame (non-responsive) delegations. If a disconnected network numbered under this policy is to be connected to the Internet, only then should name servers be permitted. I suppose that this policy is not intended to differentiate among Internet-connected networks and non-connected. The point of restricting name servers is not to differentiate within the policy, the point is to limit the spread of lame DNS delegations. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From billd at cait.wustl.edu Thu Apr 14 12:04:19 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 14 Apr 2005 11:04:19 -0500 Subject: [ppml] comments on 2004-3 Message-ID: Edward, Thanks for the time and consideration..and the explicit feedback you provide related to these policy proposals. Being concise and specific allows easy assessment of your comments. Bill Darte ARIN Advisory Council 314 935-7575 > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Edward Lewis > Sent: Thursday, April 14, 2005 10:26 AM > To: ppml at arin.net > Cc: ed.lewis at neustar.biz > Subject: [ppml] comments on 2004-3 > > > http://www.arin.net/policy/proposals/2004_3.html > > # End-users not currently connected to an ISP and/or not > planning to be # connected to the Internet are encouraged to > use private IP address numbers # reserved for non-connected > networks (see RFC 1918). When private, # non-connected > networks require interconnectivity and the private IP address > # numbers are ineffective, globally unique addresses may be > requested and # used to provide this interconnectivity. > > I would like to add that these registrations are barred from listing > name servers. > > If these networks are truly "not...connected to the Internet" then > there is no reason to list name servers for these networks in the > Internet-viewable DNS and APID (ARIN Public Information Database). > There would be no reason for the registrant to operate name servers > on the public Internet for these unreachable destinations. > > Without barring name servers on these networks, there is potential > for lame (non-responsive) delegations. > > If a disconnected network numbered under this policy is to be > connected to the Internet, only then should name servers be permitted. > > I suppose that this policy is not intended to differentiate among > Internet-connected networks and non-connected. The point of > restricting name servers is not to differentiate within the policy, > the point is to limit the spread of lame DNS delegations. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -=-=-=-=-=-=- > Edward Lewis > +1-571-434-5468 > NeuStar > > If you knew what I was thinking, you'd understand what I was saying. > From marla_azinger at eli.net Thu Apr 14 12:18:40 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 14 Apr 2005 09:18:40 -0700 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations Message-ID: <10ECB7F03C568F48B9213EF9E7F790D209B11B@wava00s2ke2k01.corp.pvt> I must say there has been alot of good informative debate on this policy. However, I hope everyone realizes that the Lame Delegation Policy "meaning" itself is not what this policy proposal is about. The only reason this proposal is in front of the community is to ask permission to deviate from the strict "notification" guidelines that were included within the original approved policy. ARIN staff will continue to carry out this policy as written...they just need some breathing room to work the notification process as fit per customer. This proposal is ONLY a modification to the "notification" part of the policy. That said...if anyone should choose to suggest changes to the actual Policy and its "meaning" then I urge you to bring it up seperately at the open sessions so that your concerns get heard and evaluated. AND so that we do not bog down our proposal to "modify" the "notification process" within the policy. Thank you Marla Azinger Electric Lightwave -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Edward Lewis Sent: Wednesday, April 13, 2005 3:49 PM To: David Conrad Cc: Paul Vixie; ppml at arin.net Subject: Re: [ppml] Policy Proposal 2005-3: Lame Delegations At 12:19 -0700 4/13/05, David Conrad wrote: >On Apr 13, 2005, at 11:11 AM, Paul Vixie wrote: >>> Why? Why is this nessasary? If someone's got their in-addr.arpa stuff >>> broken, it's not really hurting anyone but themselves. Seems like this >>> is a waste of ARIN resources to me. >> i don't agree. bad or missing in-addr.arpa or ip6.arpa data hurts us all. > >While I do not necessarily disagree, can you expand on why you believe lack of >reverse information hurts us? I see Paul has answered this, but I think that there's a non-sequiter here. The lame delegation policy is meant to trim bad referrals from an ARIN managed name server to a supposedly running server that is not. The point isn't the worthiness of the reverse map at all - the point is the health of what is there. Paul's "bad or missing" - IMHO - refers to data incorrectly stating that DNS is running on a system and/or "missing" servers, not to the presence or absence of "name servers on a network block." Incorrect referrals have induced some DNS implementations to overly burden the root servers (and others). Partly to blame is the convention of a name server, in claiming lameness, is to refer the requestor back to the root. Unwary implementations would loop forever. Wary implementations that just won't take an intermediate "no" for an answer keep pounding away too. Such observations led to the original lame delegation policy. As someone who lives and breathes DNS, I can't imagine why a network operator wouldn't have at least a stub zone for their address range mostly because it's so trivial to set up and some DNS-using applications expect there to be something. But I won't go so far as to say that the reverse map is mandatory. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From narten at us.ibm.com Thu Apr 14 12:56:38 2005 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 14 Apr 2005 12:56:38 -0400 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: Message from Michael.Dillon@radianz.com of "Thu, 14 Apr 2005 11:35:27 BST." Message-ID: <200504141656.j3EGuc8W009164@rotala.raleigh.ibm.com> > We have to allocate PI addresses to these so-called > end-sites because to do otherwise is restraint of trade. > However, it is unwise and imprudent to offer them /48 > prefixes which are highly wasteful of global router capacity I would like to hear from router vendors that they actually do intend to do this sort of optimization. The reason I ask is that even if 99% of the routes one deals with are short prefixes (e.g., /32) there will always be a need to deal with longer ones too. E.g., for routes within your AS, etc. So I'm not sure the above arguement actually holds water at the end of the day. > when we could give them shorter /32 prefixes. In doing so > we are leveraging the vast oversupply of IPv6 address space > to help conserve the processor, memory, and circuit capacity > of network operators. One reason why I would not want to give end sites a /32 in this case is that at some point in the future, there may well be a need to filter prefixes in order to keep the routing system working. If everyone gets the same size (big) prefix (big ISPs with lots of customers, and relatively small end sites that happen to be furtunate enough to join the ASN land grab), there will be no way to filter (sensibly) on those that do aggregate vs. those that do not. That is not a place I'd like to be. At some point in the future, when filtering is _required_ to keep the routing infrastructure functioning, ISPs will want to be able to impose filtering that makes at least some sense. Giving everyone equal size prefixes pretty much ensures that will never happen, because they will all look the same. Thomas From iggy at merit.edu Thu Apr 14 13:12:10 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Thu, 14 Apr 2005 13:12:10 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D209B11B@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D209B11B@wava00s2ke2k01.corp.pvt> Message-ID: That is all well and good... and quite frankly I personaly appreate the discussion that just took place... as it attempted to answer my question to Why? Why is any of this effort to get rid of lame delegation nessasary. Now that I've got the answer(for the most part) and also done further research on my own. I think the policy proposal is full of problems and I would not support it at this time. I'll try to sumerise what I find objectionable and/or confused by... (with regard to the proposal itself) First off, we are told that lame delegations are a problem, and there needs to be action taken to correct it. I'll accept that there at least is the potential for overloded servers by just leaving lame delegations alone, however I see no data that would indicate exactly how big a problem it is. Next we are asked by the AC to get rid of the current procedures for contacting the people responsible for the servers that are suposed to be lame. The reason we are asked to remove the details of the procedures for contacting these people, is because ARIN staff apparently don't have time to do it all. Yet we aren't told what parts of the current procedures are taking up all the time. We also have been given no data to indicate how much time is currently spent in trying to eradicate lame delegations. For now, lets just consider those two points... We don't know how big of a problem lame delegations are in terms of server load and we don't know how much time is spent trying to get rid of lame delegations. All we know is that ARIN staff apparently is unable to keep up with the current methods for getting rid of the lame delegations. For all I know, it might be a better use of ARIN resources to beef up the servers. So, aside from not having enough information to make a wise choice on the above to points... I think it's important there be clear statements about the steps that will be taken before deleting a lame delegation. I'm no lawyer but I would think that there could be some liablity issues involved if you simply start removing delegations to the in-addr.arpa space without clearly stating the policy and procedures. With the current policy, at least there is clear wording that describes how the attempted contacts will proceed, and how long ARIN will wait before deleting a 'lame' delegation. While eliminating this wording may help ARIN staf, it's not clear it helps ARIN customers much. I also don't like that nether the current or proposed policys would be clear as to wether a whole CIDR blocks worth of delegations will be droped when there may only be one portion of that block being actualy lame... Well I said I was going to sumerise this... I haven't made much progress in doing that yet... but I guess as close as I can get is... I can not support the "Policy Proposal 2005-3: Lame Delegations" since I see numorious flaws with it. I also have virtualy no data that would help me make an informed decsion about this proposal. Glenn On Thu, 14 Apr 2005, Azinger, Marla wrote: > I must say there has been alot of good informative debate on this policy. > > However, I hope everyone realizes that the Lame Delegation Policy > "meaning" itself is not what this policy proposal is about. The only > reason this proposal is in front of the community is to ask permission > to deviate from the strict "notification" guidelines that were included > within the original approved policy. ARIN staff will continue to carry > out this policy as written...they just need some breathing room to work > the notification process as fit per customer. > > This proposal is ONLY a modification to the "notification" part of the policy. > > That said...if anyone should choose to suggest changes to the actual Policy and its "meaning" then I urge you to bring it up seperately at the open sessions so that your concerns get heard and evaluated. AND so that we do not bog down our proposal to "modify" the "notification process" within the policy. > > Thank you > Marla Azinger > Electric Lightwave > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > Edward Lewis > Sent: Wednesday, April 13, 2005 3:49 PM > To: David Conrad > Cc: Paul Vixie; ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2005-3: Lame Delegations > > > At 12:19 -0700 4/13/05, David Conrad wrote: > >On Apr 13, 2005, at 11:11 AM, Paul Vixie wrote: > >>> Why? Why is this nessasary? If someone's got their in-addr.arpa stuff > >>> broken, it's not really hurting anyone but themselves. Seems like this > >>> is a waste of ARIN resources to me. > >> i don't agree. bad or missing in-addr.arpa or ip6.arpa data hurts us all. > > > >While I do not necessarily disagree, can you expand on why you believe lack of > >reverse information hurts us? > > I see Paul has answered this, but I think that there's a non-sequiter here. > > The lame delegation policy is meant to trim bad referrals from an > ARIN managed name server to a supposedly running server that is not. > The point isn't the worthiness of the reverse map at all - the point > is the health of what is there. > > Paul's "bad or missing" - IMHO - refers to data incorrectly stating > that DNS is running on a system and/or "missing" servers, not to the > presence or absence of "name servers on a network block." > > Incorrect referrals have induced some DNS implementations to overly > burden the root servers (and others). Partly to blame is the > convention of a name server, in claiming lameness, is to refer the > requestor back to the root. Unwary implementations would loop > forever. Wary implementations that just won't take an intermediate > "no" for an answer keep pounding away too. Such observations led to > the original lame delegation policy. > > As someone who lives and breathes DNS, I can't imagine why a network > operator wouldn't have at least a stub zone for their address range > mostly because it's so trivial to set up and some DNS-using > applications expect there to be something. But I won't go so far as > to say that the reverse map is mandatory. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > If you knew what I was thinking, you'd understand what I was saying. > > !DSPAM:425e98c0129051373527317! > > From michel at arneill-py.sacramento.ca.us Thu Apr 14 13:26:22 2005 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 14 Apr 2005 10:26:22 -0700 Subject: [ppml] 2005-1 and/or Multi6 Message-ID: >> Michael Dillon wrote: >> We have to allocate PI addresses to these so-called >> end-sites because to do otherwise is restraint of trade. >> However, it is unwise and imprudent to offer them /48 >> prefixes which are highly wasteful of global router capacity > Thomas Narten wrote: > I would like to hear from router vendors that they actually > do intend to do this sort of optimization. Ditto. > The reason I ask is that even if 99% of the routes one > deals with are short prefixes (e.g., /32) there will > always be a need to deal with longer ones too. E.g., > for routes within your AS, etc. So I'm not sure the above > arguement actually holds water at the end of the day. On the two implementations I have seen (not recently), one uses a fixed 64-bit number to store the routing prefix and the other a fixed 128-bit number (in order to allow things such as /127 ptp links to work). It takes more CPU to store and sort a table composed of variable length elements than it takes with a table of fixed-length elements, and it is more difficuly to design hardware to do so as well; not to mention more opportunities for bugs. Variable-length elements are a valid option for text fields, not for routing prefixes. Speed and robustness vs. storage efficiency, speed wins especially when it allows your favorite vendor to sell you memory at outrageous prices :-) Michael, at the end of the day your 48-bit prefix takes the same amount of RAM than the 32-bit prefix: 64 and possibly 128 bits anyway. The justification to allocate shorter prefixes is valid only when organizations begin to need more than one. Given that 64k subnets is enough for most and that allocations made using RFC3531 will extend the initial /48 to a /47 for the few large organizations that require it, I don't see any advantages in giving /32s away to sites. Michel. From owen at delong.com Thu Apr 14 13:49:41 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Apr 2005 10:49:41 -0700 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: Message-ID: <2147483647.1113475781@imac-en0.delong.sj.ca.us> > First, an IPv6 /32 is the same percentage of the total address > space as an IPv4 /32. So I don't view this as being wasteful in > any way. Second, an AS number holder has already met some > qualifications to get the AS number and I think that should > be sufficient to also get an IPv6 /32. > An AS holder that needs a /32 instead of a /48 should have no problem meeting the current guidelines for getting a /32. To claim that this is not wasteful simply because it is the same percentage of total space is absurd. Waste is measured in terms of efficient resource utilization. Using 1 address for a host (an IPv4 /32) is about as non-wasteful as you can get. OTOH, using 2^96 addresses for one host, or, even for 1,000,000 hosts is quite a bit more wasteful. I'm not saying that waste in this case is necessarily harmful, but, I do think it should still be avoided unless there is compelling reason to commit such waste. > And most importantly, I think it would be BAD precedent > for ARIN to encourage the insertion of LONG prefixes in > the global IPv6 routing table. Router manufacturers have > some options to optimize their implementations if all > PI prefixes are 32 bits or less. If we start issuing lots > of /48s then we steal away that opportunity for optimizing > the router hardware. That would be bad. > What exactly, in modern hardware, do you think can be optimized at 32 bits that can't be optimized at 64? Routers will have to be able to route longer prefixes in a variety of scenarios that have nothing to do with the RIR allocation size. Any router which optimizes IPv6 routing for /32s and shorter will be fairly broken. OTOH, if you optimize for /64 or less, there's no reason not to hand out /48s, and, the router will work in the currently defined IPv6 world. 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 Thu Apr 14 13:46:16 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 14 Apr 2005 13:46:16 -0400 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D209B11B@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D209B11B@wava00s2ke2k01.corp.pvt> Message-ID: At 9:18 -0700 4/14/05, Azinger, Marla wrote: >That said...if anyone should choose to suggest changes to the actual Policy >and its "meaning" then I urge you to bring it up seperately at the open >sessions so that your concerns get heard and evaluated. AND so that we do >not bog down our proposal to "modify" the "notification process" within the >policy. If there is interest in doing this, I'll pitch in. On Sunday I plan to do some slides during the open policy discussion on "Community-Provided Technical Guidance to ARIN." The impetus for the slides are issues such as the lame delegation policy. I have some first hand knowledge on the topic of lame delegation and the ARIN policy. Having once been on staff, one of my duties involved researching, measure, and implementing tools in support of the policy. Given the appropriateness of ARIN's confidentiality policy I won't go into details, give size estimates, nor cite specific "interesting" cases. However, I can say that the policy as written left a lot open to interpretation. By that I mean, when I wrote the tools, I made simplifying assumptions because there was little documentation behind the original policy and little guidance in the policy regarding the testing parameters. Detecting lame delegations is not as straightforward as it sounds. (My slides Sunday propose a WG, which might be what would have helped me in making more informed assumptions.) The assumptions were mine - history has shown me that I do not always make wise decisions. Note, not an attack on any judgement(s) made by staff, just speaking from experience of one-time implementer who would have appreciated better metrics by which to know when my code was "done." That being said - the modification (policy 2005-3) solves a problem with the original policy (2002-1). It is needed. The reporting scheme indicated in 2002-1 is overly burdensome. The modification is better because it allows the staff now to use it's judgement in how to report lame delegations. My questions regarding the original policy are not critical, but I have a mild engineer's burn to iron them out. I think it would be good for community members to think about how far we want the staff to go in hunting and eliminating lame delegations. This is something needing a discussion in a working group-like setting, not a policy statement. (Again, another plug for my slides on Sunday.) If this is something only I am concerned with, I'll just let it go. My concerns are not deep-seated and there are plenty of other things to work on. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owen at delong.com Thu Apr 14 14:17:15 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Apr 2005 11:17:15 -0700 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: Message-ID: <2147483647.1113477435@imac-en0.delong.sj.ca.us> >> I can remember modem manufacturers saying that when 2400bps modems >> were state of the art. > > Good example. Modems got faster and faster and then, at 56kbps, > development hist a brick wall. Today, there are no modems > faster than 56kbps because the laws of physics come to play. However, at one time, the modem developers were claiming that 2400 bps was the physical limit of telecom. Later, those same developers claimed that V.32 was the physical limit. Now, it's 56k. The physical limits of the telephone system have not changed during all of these changes in so-called physical limit. What changed was we found new ways to take advantage of the same physical properties. Sure, single-atom wide wire is a physical limit. However, single molecule wire is many many many cycles of Moore's law away from where we are today. Today, most semiconductors are made of fairly large molecules. in the future, we may find ways to use smaller molecules, or even atoms. In the future, we may find alternatives to wire. The reason modems haven't advanced beyond 56k is because there is no market to support the research to do so. Beyond 56k, there is ISDN, DSL, Frame Relay, ATM, etc. Modem research stalled because 56k is fast enough for those rare circumstances in which a modem is still the best form of communication, and, those circumstances are becoming increasingly rare, thus lowering the potential value of said market. It has much more to do with the inability to create a market for the product than the ability to achieve improvement. 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 Thu Apr 14 14:17:01 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 14 Apr 2005 14:17:01 -0400 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D209B11B@wava00s2ke2k01.corp.pvt> Message-ID: At 13:12 -0400 4/14/05, Glenn Wiltse wrote: > First off, we are told that lame delegations are a problem, and >there needs to be action taken to correct it. I'll accept that there >at least is the potential for overloded servers by just leaving lame >delegations alone, however I see no data that would indicate exactly >how big a problem it is. Back when 2002-1 was derived, this talk was all the rage: http://www.nanog.org/mtg-0210/wessels.html In it, only 2% of the load at a root server was considered "legitimate." The report does not come out and finger lame delegations, but one implementation confronted with lame delegations would send repeated queries. Repeated queries have many causes, and totalled 25% of the load (10~12x the legit.) I wish I knew of a reference to the linkage of lame delegations to repeated queries. Does anyone know of one? (The discussion leading to 2002-1 happened before I spent time on ARIN issues.) > Next we are asked by the AC to get rid of the current procedures >for contacting the people responsible for the servers that are suposed >to be lame. The reason we are asked to remove the details of the >procedures for contacting these people, is because ARIN staff apparently >don't have time to do it all. Yet we aren't told what parts of the current >procedures are taking up all the time. We also have been given no data >to indicate how much time is currently spent in trying to eradicate >lame delegations. Detecting lame delegations and reporting lame delegations are two steps in the process. 2002-1 is vague on the first, meaning that there is no issue with 2002-1 regarding "how" to test. (I am suggesting that maybe the community does want to look at that.) 2002-1 is very specific on the reporting step, however, and what 2002-1 requires is not scaleable. 2005-3 is trying to fix that. The policy 2005-3 is not removing the procedures for contacting folks, just making the procedure a matter for the staff to determine. Staff has a better determination of work load and resources. Telling the staff "how" (as 2002-1 does) is micro-management. Telling staff "what" (as 2005-3 does) is a more appropriate specification of a "service." > For now, lets just consider those two points... We don't know how >big of a problem lame delegations are in terms of server load and we >don't know how much time is spent trying to get rid of lame delegations. >All we know is that ARIN staff apparently is unable to keep up with >the current methods for getting rid of the lame delegations. For all >I know, it might be a better use of ARIN resources to beef up the >servers. This is an over simplification. Testing ARIN's delegations is not the long-pole in the tent. Deciding what delegations need to be remedied is not the long-pole in the tent. Informing the registrants that they need to fix something is the long-pole in the tent. Enforcing the policy by trimming bad delegation information is not the long pole. One problem with informing registrants is - where do you draw the line between presenting a diagnosis and prescribing a fix? Not all registrants use BIND, so putting up BIND-specific "steps to fix" is unfair to registrants using other implementations. Once you do decide what to present to registrants, how is not always clear. Contact by e-mail is clear, but it is not guaranteed to work. It's supposed to, but not all e-mail addresses are current - evidence of that is in 2002-1 which says that the next step is phone and postal. As I mention in another mail, I was once close to this problem. It would be inappropriate for me to go into details because of confidentiality rules. However, the "for all I know" statement you give is a reason why I would like to see some input from the staff towards these discussions - if just to give us (members) an estimate of the costs of the policies, and perhaps where a policy can be adjusted to result in a significant savings without a loss of service. > So, aside from not having enough information to make a wise choice >on the above to points... > > I think it's important there be clear statements about the steps >that will be taken before deleting a lame delegation. I'm no lawyer >but I would think that there could be some liablity issues involved >if you simply start removing delegations to the in-addr.arpa space >without clearly stating the policy and procedures. With the current >policy, at least there is clear wording that describes how the attempted >contacts will proceed, and how long ARIN will wait before deleting >a 'lame' delegation. While eliminating this wording may help ARIN staf, >it's not clear it helps ARIN customers much. That is the concern that I believe (speaking as someone not in the know as I wasn't involved in the lead up to 2002-1) the original policy was so specific on this point. Still, I think that the staff is responsible enough to carry this out - there are other legal protections and liability protections in place. There is also legal council available. > I also don't like that nether the current or proposed policys would >be clear as to wether a whole CIDR blocks worth of delegations will >be droped when there may only be one portion of that block being actualy >lame... Well, this is a topic I would like to see discussed in a technically-bent arena. One solution, which causes the least amount of liability concerns (see above) is to retain all delegations wherein one delegation is healthy. This could be categorized as "getting the low hanging fruit." Not complete, but better than nothing at all. > Well I said I was going to sumerise this... I haven't made much >progress in doing that yet... but I guess as close as I can get is... > >I can not support the "Policy Proposal 2005-3: Lame Delegations" since >I see numorious flaws with it. I also have virtualy no data that would >help me make an informed decsion about this proposal. I sympathize with your plight. However, given my angle on this, 2005-3 is a step in the right direction. If we go no further, we will be better off. If we do decide to form a discussion on this topic, I think we can wind up with a technically better pruning of the DNS tree. The question remains if the better pruning would be worth the cost. > >Glenn > >On Thu, 14 Apr 2005, Azinger, Marla wrote: > >> I must say there has been alot of good informative debate on this policy. >> >> However, I hope everyone realizes that the Lame Delegation Policy >> "meaning" itself is not what this policy proposal is about. The only >> reason this proposal is in front of the community is to ask permission >> to deviate from the strict "notification" guidelines that were included >> within the original approved policy. ARIN staff will continue to carry >> out this policy as written...they just need some breathing room to work >> the notification process as fit per customer. >> >> This proposal is ONLY a modification to the "notification" part of >>the policy. >> >> That said...if anyone should choose to suggest changes to the >>actual Policy and its "meaning" then I urge you to bring it up >>seperately at the open sessions so that your concerns get heard and >>evaluated. AND so that we do not bog down our proposal to "modify" >>the "notification process" within the policy. >> >> Thank you >> Marla Azinger >> Electric Lightwave >> >> -----Original Message----- >> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of >> Edward Lewis >> Sent: Wednesday, April 13, 2005 3:49 PM >> To: David Conrad >> Cc: Paul Vixie; ppml at arin.net >> Subject: Re: [ppml] Policy Proposal 2005-3: Lame Delegations >> >> >> At 12:19 -0700 4/13/05, David Conrad wrote: >> >On Apr 13, 2005, at 11:11 AM, Paul Vixie wrote: >> >>> Why? Why is this nessasary? If someone's got their in-addr.arpa stuff >> >>> broken, it's not really hurting anyone but themselves. Seems like this >> >>> is a waste of ARIN resources to me. >> >> i don't agree. bad or missing in-addr.arpa or ip6.arpa data >>hurts us all. >> > >> >While I do not necessarily disagree, can you expand on why you >>believe lack of >> >reverse information hurts us? >> >> I see Paul has answered this, but I think that there's a non-sequiter here. >> >> The lame delegation policy is meant to trim bad referrals from an >> ARIN managed name server to a supposedly running server that is not. >> The point isn't the worthiness of the reverse map at all - the point >> is the health of what is there. >> >> Paul's "bad or missing" - IMHO - refers to data incorrectly stating >> that DNS is running on a system and/or "missing" servers, not to the >> presence or absence of "name servers on a network block." >> >> Incorrect referrals have induced some DNS implementations to overly >> burden the root servers (and others). Partly to blame is the >> convention of a name server, in claiming lameness, is to refer the >> requestor back to the root. Unwary implementations would loop >> forever. Wary implementations that just won't take an intermediate >> "no" for an answer keep pounding away too. Such observations led to >> the original lame delegation policy. >> >> As someone who lives and breathes DNS, I can't imagine why a network >> operator wouldn't have at least a stub zone for their address range >> mostly because it's so trivial to set up and some DNS-using >> applications expect there to be something. But I won't go so far as >> to say that the reverse map is mandatory. >> >> -- >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Edward Lewis +1-571-434-5468 >> NeuStar >> >> If you knew what I was thinking, you'd understand what I was saying. >> >> !DSPAM:425e98c0129051373527317! >> >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owen at delong.com Thu Apr 14 14:25:40 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Apr 2005 11:25:40 -0700 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <20050414135818.GA1099@srv01.cluenet.de> References: <20050414111413.GA32095@srv01.cluenet.de> <20050414135818.GA1099@srv01.cluenet.de> Message-ID: <2147483647.1113477940@imac-en0.delong.sj.ca.us> > ACK. But then we'd need BGP5. Question is, wether we shouldn't THEN > actually move to a new model which really seperates identity and locator > _from_the_beginning_ and not crammed over IP/TCP/... > We absolutely need to do this eventually. Until we do, there are a number of issues that remain in the "too-hard" bucket: + Easy renumbering (remember v6 was supposed to fix this, then abandoned it) + ACL management (relates main cause of abandoning easy renumbering) + Routing Table Growth + Ubiquitous multi-homing + NAT Impacts on Peer-to-Peer capabilities I am looking for collaborators to work with me on developing a proposal to float before IETF which I think addresses this need, but, I am not a protocol development expert, and, I would like to find someone who understands the protocol issues better than myself who would like to work with me on this. If anyone on this list has interest, send me an email off-list and I will forward you what I have so far. 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 kloch at hotnic.net Thu Apr 14 14:32:07 2005 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 14 Apr 2005 14:32:07 -0400 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <2147483647.1113475781@imac-en0.delong.sj.ca.us> References: <2147483647.1113475781@imac-en0.delong.sj.ca.us> Message-ID: <425EB727.4040907@hotnic.net> Owen DeLong wrote: > An AS holder that needs a /32 instead of a /48 should have no > problem meeting the current guidelines for getting a /32. > To claim that this is not wasteful simply because it is the > same percentage of total space is absurd. Waste is measured > in terms of efficient resource utilization. Using 1 address > for a host (an IPv4 /32) is about as non-wasteful as you > can get. OTOH, using 2^96 addresses for one host, or, even > for 1,000,000 hosts is quite a bit more wasteful. I'm not > saying that waste in this case is necessarily harmful, but, > I do think it should still be avoided unless there is > compelling reason to commit such waste. The real waste is the wase of bandwidth and memory for carrying bits 64-127. Since we're stuck with that... For prefixes /32 and longer, allocations should be filter friendly and promote aggregation first, and relatively efficient second. I am concerned about prefixes much shorter than /32, and think the HD ratio should be re-evaluated as suggested in this draft: http://www.ietf.org/internet-drafts/draft-huston-hd-metric-00.txt - Kevin From kloch at hotnic.net Thu Apr 14 14:36:42 2005 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 14 Apr 2005 14:36:42 -0400 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <200504141656.j3EGuc8W009164@rotala.raleigh.ibm.com> References: <200504141656.j3EGuc8W009164@rotala.raleigh.ibm.com> Message-ID: <425EB83A.40109@hotnic.net> Thomas Narten wrote: > At some point in the future, when filtering is _required_ to keep the > routing infrastructure functioning, ISPs will want to be able to > impose filtering that makes at least some sense. Giving everyone equal > size prefixes pretty much ensures that will never happen, because they > will all look the same. If /32's were allocated out of a distinct block of addresses they would be easy to identify. But identification isn't enough. As long as there are /32's that aren't filtered it will be hard to say some /32's are "good" and other /32's are "bad." Especially in the real world of cash, lawyers and government. This is the same reason I suggested it might not be wise to use /48 for end sites. "how can you justify filtering my (deaggregated) /48 when you don't filter all those other /48's?" - Kevin From Ed.Lewis at neustar.biz Thu Apr 14 14:58:00 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 14 Apr 2005 14:58:00 -0400 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <2147483647.1113477435@imac-en0.delong.sj.ca.us> References: <2147483647.1113477435@imac-en0.delong.sj.ca.us> Message-ID: Admittedly OT...but I'm curious if what I've learned "way back when" is untrue. At 11:17 -0700 4/14/05, Owen DeLong wrote: >The reason modems haven't advanced beyond 56k is because there is >no market to support the research to do so. Beyond 56k, there >is ISDN, DSL, Frame Relay, ATM, etc. Modem research stalled >because 56k is fast enough for those rare circumstances in which >a modem is still the best form of communication, and, those >circumstances are becoming increasingly rare, thus lowering the >potential value of said market. It has much more to do with >the inability to create a market for the product than the ability >to achieve improvement. My recollection is that 56k represents the number of bits a DS0 is allocated in a T-1 trunked voice frame, once you discount the DS0 channel's signalling bit. Being a life-long networker and not a bell-head, I'd be curious if that wasn't the reason for the limit. The way it was taught to me, and repeated by me in class, from Tannenbaum's text book.: 24 DS0's were sampled a 7 bits every 8000 times per second at CODEC's and then assembled into a T-1 frame. 7b x 8000/sec = 56kbps (where k=1000). 24 of these w/1 signalling bit, plus one more frame-wide signalling bit: = {(24 x [7+1]) + 1 = 193} * 8000/sec = 1.544 Mbps or 1,544,000 bps. T-1's don't all use the same framing, the above is for voice, but a voice frame is appropriate for a modem. I always thought that the 56k limit was the fastest obtainable bit rate over trunked telephone lines because of the CODECs. With compression, higher effective bit rates may be possible for applications, but the real physical limit was 56k - or so I have been led to believe. (Compression is not always possible, true random data cannot be compressed.) 8000/sec is the limit of reasonable sampling for a 4KHz bandwidth which is optimized for human hearing. SONET also uses 8000/sec for it's basic frequency. I've also been told that in some regions, fiber was used that lowered the bandpass to about 3300 or 3200 KHz, meaning that even 56kbps would be unobtainable. I've also been told that the higher rates of ?DSL are possible because the non-customer end of the circuit terminates before the trunking CODEC. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From iggy at merit.edu Thu Apr 14 15:11:22 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Thu, 14 Apr 2005 15:11:22 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <423AF7D4.9010803@arin.net> References: <423AF7D4.9010803@arin.net> Message-ID: I still have many concerns about this policy, as currently written and proposed. However in the interest of trying to help get something changed now, that may help ARIN staff actualy do what policy intends without overly burdening the current staff, I will suggest the following that would make this proposal less objectionable to me. I think at the very minimum there should be some statement that indicates how long a lame delegation has been known to be 'lame' before that lame delegation is to be removed. Say, something like the following... "After attempting to contact the domain holder and confirming that the lame delegation persists for a minimum of 45 days, ARIN will update the database that will result in a removal of the lame delegation." A statment simmilar to that, would at least give some clarity to what would minimaly take place before any removal of delegations would occur, and I think this would be a good thing. FYI - I took most of those words directly from the APNIC's policy, which incedentaly is even more detailed then ARIN's currently is... http://www.apnic.net/services/rev-del/index.html Glenn Wiltse On Fri, 18 Mar 2005, Member Services wrote: > 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 dr at cluenet.de Thu Apr 14 20:05:22 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 15 Apr 2005 02:05:22 +0200 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: Message-ID: <20050415000522.GA6917@srv01.cluenet.de> On Thu, Apr 14, 2005 at 07:56:49AM -0700, Michel Py wrote: > Actually, I was discussing this privately with someone from vendor J > recently, they have warned publicly for a while that they are not sure > that they will be able to ride Moore's law. > This was presented in May 2003: > > http://arneill-py.sacramento.ca.us/ipv6mh/IPv6%20Transition.ppt#888,37,P > ossible Solution #1: Do Nothing > > or go to slide 37 of > http://arneill-py.sacramento.ca.us/ipv6mh/IPv6%20Transition.ppt > [slow server....] Well, it says "No guarantee". Of course there is a never a guaratee. Still it's different from saying "We have serious doubts...", which would be a warning. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Michael.Dillon at radianz.com Fri Apr 15 05:50:09 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 15 Apr 2005 10:50:09 +0100 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: <200504141656.j3EGuc8W009164@rotala.raleigh.ibm.com> Message-ID: > > We have to allocate PI addresses to these so-called > > end-sites because to do otherwise is restraint of trade. > > However, it is unwise and imprudent to offer them /48 > > prefixes which are highly wasteful of global router capacity > > I would like to hear from router vendors that they actually do intend > to do this sort of optimization. I don't think that this is relevant to making policy. For one thing, we cannot be certain which router vendors to ask since it is entirely possible that a new vendor will start up at some point in the future and will include this feature in their implementation as part of their differentiation from existing products. And a vendor who says today, that they will not do such an optimization, could well change their mind tomorrow. We should not uneccesarily limit the choices of router vendors. > The reason I ask is that even if 99% > of the routes one deals with are short prefixes (e.g., /32) there will > always be a need to deal with longer ones too. E.g., for routes within > your AS, etc. So I'm not sure the above arguement actually holds water > at the end of the day. The fact that the router needs to deal with some long prefixes does not prevent the vendor from providing hardware acceleration for the first 32 bits of a prefix. We really should not be getting into design details here. It is enough to realize that longer prefixes require greater capacity of various router resources. > One reason why I would not want to give end sites a /32 in this case > is that at some point in the future, there may well be a need to > filter prefixes in order to keep the routing system working. I don't want to give end sites a /32. I want to give a /32 to any network which is multihomed. I don't consider a multihomed network to be an end site from a network topology point of view. I know that many ISPs consider such networks to be end sites because of their business model, but our policy should be independent of business models. > At some point in the future, when filtering is _required_ to keep the > routing infrastructure functioning, ISPs will want to be able to > impose filtering that makes at least some sense. Giving everyone equal > size prefixes pretty much ensures that will never happen, because they > will all look the same. If we ever get to that day, then ISPs could charge a fee to carry entries in their routing table. The filtering (and BGP peering) will not be done by routers directly but by separate route servers which can do complex filtering and damping. --Michael Dillon From Michael.Dillon at radianz.com Fri Apr 15 05:57:55 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 15 Apr 2005 10:57:55 +0100 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: Message-ID: > It > takes more CPU to store and sort a table composed of variable length > elements than it takes with a table of fixed-length elements, and it is > more difficuly to design hardware to do so as well; not to mention more > opportunities for bugs. Variable-length elements are a valid option for > text fields, not for routing prefixes. Speed and robustness vs. storage > efficiency, speed wins especially when it allows your favorite vendor to > sell you memory at outrageous prices :-) Yes, speed wins. And router vendors have introduced more and more complex designs over time in order to get higher speed. This includes optimizing software algorithms and shifting functions into hardware such as FPGAs and TCAMs. > Michael, at the end of the day your 48-bit prefix takes the same amount > of RAM than the 32-bit prefix: No, at the end of the day it does not. Today it does, but we are making an IPv6 policy that should last for many years. I don't expect router design to stand still during that time and I also don't expect any router vendors to reveal what they are working on in their research labs. At the end of the day, it is possible to optimize by processing fewer bits and we should not remove that option from the table by making bad policy and introducing yet another class of IPv6 address. > Given that 64k subnets is > enough for most and that allocations made using RFC3531 will extend the > initial /48 to a /47 for the few large organizations that require it, I > don't see any advantages in giving /32s away to sites. If an organisation has an AS number then their network is not a "site". --Michael Dillon From iggy at merit.edu Fri Apr 15 10:34:02 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Fri, 15 Apr 2005 10:34:02 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <422F66F3.3090606@arin.net> References: <422F66F3.3090606@arin.net> Message-ID: I've got ALOT of concerns about this proposal. More then I do with 2005-3. Ed Lewis rasied several good points that I too am concerned about relating to this proposal. Many of these terms such as SUSPEND, reclaim, offenders, or even non-responsive, don't seem to be defined very well if at all. The problems I have with this proposal are too numerous to go into in every detail right now. Let me just ask about 'reclaim' a resource... Does that mean if a ISP should assign a /24 to a customer, and that customer should commit these 'offenses', do you then reclaim a whole /14 or larger resorce that the /24 is part of? Aside from these concerns... If ARIN staff don't have time to track down 'lame delegation' offenders... how are they ever going to tackle this job being proposed here? This is potentialy a HUGE amount of work for ARIN and for ISPs with large amounts of re-assignment information. I think this is way too agressive of a aproach. I will not support this proposal as written. Glenn Wiltse On Wed, 9 Mar 2005, 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. > > 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. > > > > !DSPAM:422f689b17078253968004! > > > From michel at arneill-py.sacramento.ca.us Fri Apr 15 11:17:10 2005 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 15 Apr 2005 08:17:10 -0700 Subject: [ppml] 2005-1 and/or Multi6 Message-ID: > Michael Dillon wrote: > Yes, speed wins. And router vendors have introduced > more and more complex designs over time in order to > get higher speed. This includes optimizing software > algorithms and shifting functions into hardware such > as FPGAs and TCAMs. Yes, but never at the expense of speed. And remember that selling memory is a good business for all vendors, even those who don't sell it at 20 times the street price. > At the end of the day, it is possible to optimize by > processing fewer bits This would have been true in the past, but not anymore. By the time the size of the routing table is so big that it requires optimization, there will be no processor that does not have a 64-bit core and processing 64-bit elements will be as fast as processing 32-bit elements. Besides, do some basic math: 1 million IPv6 routes/paths (we're not there yet, are we?) Stored at 32 bits: 4 Megabytes Stored at 48 bits: 6 Megabytes (the other associated storage such as the AS-PATH would not change) Difference: 2 Megabytes. Give me a break, this is not worth any code complexity nor custom chip design even as of today. > and we should not remove that option from the table by making > bad policy and introducing yet another class of IPv6 address. We are not introducing yet another class of IPv6 addresses. /48 for sites has always been the deal. > If an organisation has an AS number then their > network is not a "site". Where does this come from? Michel. From memsvcs at arin.net Fri Apr 15 11:19:54 2005 From: memsvcs at arin.net (Member Services) Date: Fri, 15 Apr 2005 11:19:54 -0400 Subject: [ppml] Policy Proposal 2004-8: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries Message-ID: <425FDB9A.4050506@arin.net> Policy Proposal 2004-8: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries This policy proposal was previously discussed on this mailing list and at the ARIN XIV Public Policy Meeting. Based on the feedback received from those discussions, the text of this policy proposal has been revised. The proposal will be presented at the upcoming Public Policy Meeting, April 18-20, 2005, in Orlando, Florida. The policy proposal text is below and can be found at: http://www.arin.net/policy/proposals/2004_8.html Subscription information for the ARIN Public Policy Mailing List can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### This document describes the policy governing the allocation of IPv6 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements will be specified by appropriate agreements between ICANN and the NRO. 1. Allocation Principles ? The unit of IPv6 allocation (and therefore the minimum IPv6 allocation) from IANA to an RIR is a /12 ? The IANA will allocate sufficient IPv6 address space to the RIRs to support their registration needs for at least an 18 month period. ? The IANA will allow for the RIRs to apply their own respective chosen allocation and reservation strategies in order to ensure the efficiency and efficacy of their work. 2. Initial Allocations ? On inception of this policy, each current RIR with less than a /12 unallocated address space, shall receive an IPv6 allocation from IANA ? Any new RIR shall, on recognition by ICANN receive an IPv6 allocation from the IANA 3. Additional Allocations A RIR is eligible to receive additional IPv6 address space from the IANA when either of the following conditions are met. ? The RIR's AVAILABLE SPACE of IPv6 addresses is less than 50% of a /12. ?The RIR's AVAILABLE SPACE of IPv6 addresses is less than its established NECESSARY SPACE for the following 9 months. In either case, IANA shall make a single IPv6 allocation, sufficient to satisfy the established NECESSARY SPACE of the RIR for an 18 month period. 3.1 Calculation of AVAILABLE SPACE The AVAILABLE SPACE of IPv6 addresses of a RIR shall be determined as follows: AVAILABLE SPACE = CURRENTLY FREE ADDRESSES + RESERVATIONS EXPIRING DURING THE FOLLOWING 3 MONTHS - FRAGMENTED SPACE FRAGMENTED SPACE is determined as the total amount of available blocks smaller than the RIR's minimum allocation size within the RIR's currently available stock. 3.2 Calculation of NECESSARY SPACE If the applying Regional Internet Registry does not establish any special needs for the period concerned, NECESSARY SPACE shall be determined as follows: NECESSARY SPACE = AVERAGE NUMBER OF ADDRESSES ALLOCATED MONTHLY DURING THE PAST 6 MONTHS * LENGTH OF PERIOD IN MONTHS If the applying RIR anticipates that due to certain special needs the rate of allocation for the period concerned will be different from the previous 6 months, it may determine its NECESSARY SPACE as follows: Calculate NECESSARY SPACE as its total needs for that period according to its projection and based on the special facts that justify these needs. Submit a clear and detailed justification of the above mentioned projection (Item A). If the justification is based on the allocation tendency prepared by the Regional Internet Registry, data explaining said tendency must be enclosed. If the justification is based on the application of one or more of the Regional Internet Registry's new allocation policies, an impact analysis of the new policy/policies must be enclosed. If the justification is based on external factors such as new infrastructure, new services within the region, technological advances or legal issues, the corresponding analysis must be enclosed together with references to information sources that will allow verification of the data. If IANA does not have elements that clearly question the Regional Internet Registry's projection, the special needs projected for the following 18 months, indicated in Item A above, shall be considered valid. 4. Announcement of IANA Allocations The IANA, the NRO, and the RIRs will make announcements and update their respective web sites regarding an allocation made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. From John.Sweeting at teleglobe.com Fri Apr 15 11:45:48 2005 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Fri, 15 Apr 2005 11:45:48 -0400 Subject: [ppml] comments on 2004-8 Message-ID: <1797AB680DD0D2118987009027178032183D8FBA@camtmms01.Teleglobe.CA> Ed, does the language in the proposal now meet your request below: 4. Announcement of IANA Allocations The IANA, the NRO, and the RIRs will make announcements and update their respective web sites regarding an allocation made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis at neustar.biz] Sent: 14 avril 2005 11:18 To: ppml at arin.net Cc: ed.lewis at neustar.biz Subject: [ppml] comments on 2004-8 http://www.arin.net/policy/proposals/2004_8.html # 4. Announcement of IANA allocations to the RIRs # # When address space is allocated to a RIR, the IANA will send a detailed # announcement to the receiving RIR. The IANA will also make announcements # to all other RIRs, informing them of the recent allocation. The RIRs will # coordinate announcements to their respective membership lists and any other # lists they deem necessary. This issue came up in discussing a similar policy for IPv4 by ICANN's gTLD constituency: # The suggestion relates to the second sentence of the first paragraph of # Section 4:"The IANA will also make announcements to all other RIRs, # informing them of the recent allocation." So, I'd suggest adding a sentence stating that "IANA will also announce the allocation to other interested parties." This is something that IANA ought to do, not the RIR's. The RIR's don't have the relationships with gTLDs, ccTLDs, etc., etc., that IANA has. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Fri Apr 15 11:59:33 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 15 Apr 2005 11:59:33 -0400 Subject: [ppml] comments on 2004-8 In-Reply-To: <1797AB680DD0D2118987009027178032183D8FBA@camtmms01.Teleglobe.CA> References: <1797AB680DD0D2118987009027178032183D8FBA@camtmms01.Teleglobe.CA> Message-ID: Looks good or better. The intent (within the context of ARIN discussions) is to shield ARIN from having to alert, say, the gTLDs. I might suggest this, moving mention of a specific mechanism (web sites) from a requirement to an example. " 4. Announcement of IANA Allocations The IANA, the NRO, and the RIRs will make announcements regarding an allocation made by the IANA to an RIR. Announcements will be made public via appropriate means, such as web sites and notification lists. ICANN and the NRO will establish administrative procedures to manage this process. " At 11:45 -0400 4/15/05, Sweeting, John wrote: >Ed, does the language in the proposal now meet your request below: > >4. Announcement of IANA Allocations >The IANA, the NRO, and the RIRs will make announcements and update their >respective web sites regarding an allocation made by the IANA to an RIR. >ICANN >and the NRO will establish administrative procedures to manage this process. > >-----Original Message----- >From: Edward Lewis [mailto:Ed.Lewis at neustar.biz] >Sent: 14 avril 2005 11:18 >To: ppml at arin.net >Cc: ed.lewis at neustar.biz >Subject: [ppml] comments on 2004-8 > > >http://www.arin.net/policy/proposals/2004_8.html > ># 4. Announcement of IANA allocations to the RIRs ># ># When address space is allocated to a RIR, the IANA will send a detailed ># announcement to the receiving RIR. The IANA will also make announcements ># to all other RIRs, informing them of the recent allocation. The RIRs will ># coordinate announcements to their respective membership lists and any >other ># lists they deem necessary. > >This issue came up in discussing a similar policy for IPv4 by ICANN's >gTLD constituency: > ># The suggestion relates to the second sentence of the first paragraph of ># Section 4:"The IANA will also make announcements to all other RIRs, ># informing them of the recent allocation." > >So, I'd suggest adding a sentence stating that "IANA will also >announce the allocation to other interested parties." > >This is something that IANA ought to do, not the RIR's. The RIR's >don't have the relationships with gTLDs, ccTLDs, etc., etc., that >IANA has. >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >If you knew what I was thinking, you'd understand what I was saying. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From memsvcs at arin.net Fri Apr 15 12:02:03 2005 From: memsvcs at arin.net (Member Services) Date: Fri, 15 Apr 2005 12:02:03 -0400 Subject: [ppml] Last Reminder! Remote Participation at ARIN XV Message-ID: <20050415160158.E0C0E1FE8D@mercury.arin.net> Not able to attend the ARIN XV and NAv6TF Summit in Orlando next week? You can still watch the webcast and participate remotely via e-mail! To register for remote participation, e-mail remote at arin.net with "Remote Participation" in the subject by Sunday, April 17. ARIN will send a reply e-mail with any steps necessary to complete the registration process and instructions on how to participate remotely in the meeting. Remote Participation Information ARIN XV Remote Participation Availability Monday, April 18 9AM - 12:30 PM Public Policy Meeting Tuesday, April 19 9AM - 12:30 PM Public Policy Meeting Wednesday, April 20 9AM - 12:30 PM Public Policy Meeting 2PM - 5:30 PM Members Meeting No registration is necessary for the webcast; visit http://www.arin.net/ARIN-XV/webcast.html for more information. For more information on the ARIN XV and NAv6TF Summit, visit the ARIN website at: http://www.arin.net/ARIN-XV/ All remote participants are subject to the Remote Participation Acceptable Use Policy (AUP) available at: http://www.arin.net/ARIN-XV/remote_aup.html Regards, Member Services American Registry for Internet Numbers (ARIN) From billd at cait.wustl.edu Fri Apr 15 12:15:23 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 15 Apr 2005 11:15:23 -0500 Subject: [ppml] comments on 2004-8 Message-ID: Definitely....we should always keep operational issues out of policy. We've done a bad job of that over the years....I'm involved in the blame...as I have been in it from the beginning, but we're getting better. Bill Darte ARIN Advisory Council 314 935-7575 > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Edward Lewis > Sent: Friday, April 15, 2005 11:00 AM > To: Sweeting, John > Cc: 'Edward Lewis'; ppml at arin.net > Subject: RE: [ppml] comments on 2004-8 > > > Looks good or better. The intent (within the context of ARIN > discussions) is to shield ARIN from having to alert, say, the gTLDs. > > I might suggest this, moving mention of a specific mechanism (web > sites) from a requirement to an example. > > " > 4. Announcement of IANA Allocations > > The IANA, the NRO, and the RIRs will make announcements regarding an > allocation made by the IANA to an RIR. Announcements will be made > public via appropriate means, such as web sites and notification > lists. ICANN and the NRO will establish administrative procedures to > manage this process. > " > > At 11:45 -0400 4/15/05, Sweeting, John wrote: > >Ed, does the language in the proposal now meet your request below: > > > >4. Announcement of IANA Allocations > >The IANA, the NRO, and the RIRs will make announcements and update > >their respective web sites regarding an allocation made by > the IANA to > >an RIR. ICANN and the NRO will establish administrative > procedures to > >manage this process. > > > >-----Original Message----- > >From: Edward Lewis [mailto:Ed.Lewis at neustar.biz] > >Sent: 14 avril 2005 11:18 > >To: ppml at arin.net > >Cc: ed.lewis at neustar.biz > >Subject: [ppml] comments on 2004-8 > > > > > >http://www.arin.net/policy/proposals/2004_8.html > > > ># 4. Announcement of IANA allocations to the RIRs > ># > ># When address space is allocated to a RIR, the IANA will send a > >detailed # announcement to the receiving RIR. The IANA will > also make > >announcements # to all other RIRs, informing them of the recent > >allocation. The RIRs will # coordinate announcements to their > >respective membership lists and any other # lists they deem > necessary. > > > >This issue came up in discussing a similar policy for IPv4 > by ICANN's > >gTLD constituency: > > > ># The suggestion relates to the second sentence of the first > paragraph > >of # Section 4:"The IANA will also make announcements to all other > >RIRs, # informing them of the recent allocation." > > > >So, I'd suggest adding a sentence stating that "IANA will > also announce > >the allocation to other interested parties." > > > >This is something that IANA ought to do, not the RIR's. The RIR's > >don't have the relationships with gTLDs, ccTLDs, etc., etc., > that IANA > >has. > >-- > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-=-=-=- > >Edward Lewis > +1-571-434-5468 > >NeuStar > > > >If you knew what I was thinking, you'd understand what I was saying. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -=-=-=-=-=-=- > Edward Lewis > +1-571-434-5468 > NeuStar > > If you knew what I was thinking, you'd understand what I was saying. > From Michael.Dillon at radianz.com Fri Apr 15 12:28:45 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 15 Apr 2005 17:28:45 +0100 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: Message-ID: > > At the end of the day, it is possible to optimize by > > processing fewer bits > > This would have been true in the past, but not anymore. By the time the > size of the routing table is so big that it requires optimization, there > will be no processor that does not have a 64-bit core and processing > 64-bit elements will be as fast as processing 32-bit elements. This may be true in the domain of trendy laptop and desktop computers, but I cannot believe that it will be true overall. We still have millions of 8-bit CPUs being built into devices every year and there is nothing on the horizon that indicates manufacturers will stop using them. Nowadays, these 8-bit CPUs are usually called PICs and they do jobs like manage buttons, blinking LEDs, motor control, etc. Next up is the FPGA, which is programmable at the hardware level, i.e. you can tell the device how to organize it's logic gates internally to change from being an 8086 to an ARM 7 to a 68020 to a special purpose neural network machine. In a world where reconfigurable hardware elements become faster and more powerful, the concept of "the CPU" begins to falter. If there is a speed advantage to processing 32 bit elements then there will be hardware available to do that job for the next few centuries. Ditto for variable length elements. People do not design and produce these things to follow fashion trends; they design them to do real work and meet real demands. > Besides, do some basic math: > 1 million IPv6 routes/paths (we're not there yet, are we?) > Stored at 32 bits: 4 Megabytes > Stored at 48 bits: 6 Megabytes That is arithmetic not math. If you want to do some math you would include the overhead of a trie, the average number of interfaces on a router (after all, routes point to interfaces) and the number of views that the average core router would need to carry. And a real analysis would also look at gate counts for a hardware implementation with numbers for various implementations of TCAM (Ternary Content Addressable Memory) as well as other forms of hardware encoded lookups. > (the other associated storage such as the AS-PATH would not change) > Difference: 2 Megabytes. Give me a break, this is not worth any code > complexity nor custom chip design even as of today. Maybe you should have a discussion with somebody who actually designs routers. Or just look inside a router and see if you can identify every one of the chips as a standard non-custom chip. FPGAs do not count as standard chips. > > If an organisation has an AS number then their > > network is not a "site". > > Where does this come from? That comes from way back at the beginning of the thread and the policy proposal that started it all. Should ARIN give an IPv6 PI allocation to any organization with an AS number. I am saying, Yes ARIN should do so and that PI allocation should be a /32 for reasons of prudence and conservation of future router capacities. --Michael Dillon From Michael.Dillon at radianz.com Fri Apr 15 12:33:14 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 15 Apr 2005 17:33:14 +0100 Subject: [ppml] comments on 2004-8 In-Reply-To: <1797AB680DD0D2118987009027178032183D8FBA@camtmms01.Teleglobe.CA> Message-ID: > 4. Announcement of IANA Allocations > The IANA, the NRO, and the RIRs will make announcements and update their > respective web sites regarding an allocation made by the IANA to an RIR. > ICANN > and the NRO will establish administrative procedures to manage this process. If we are going to be making modifications to this one, then I think it is time to say that these announcements and web accessible documents should be in a machine-parseable format. Something like RSS could be used or even just a plain XML page. The current IANA list of address ranges is not machine parseable and is not consistent from range to range. There is no good reason why the list of ranges produced by IANA should be broken (or aggregated) on class A boundaries. If they have this info in a database, then it should be trivial to report it as an XML file. --Michael Dillon From L.Howard at stanleyassociates.com Fri Apr 15 12:39:35 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 15 Apr 2005 12:39:35 -0400 Subject: [ppml] comments on 2004-8 Message-ID: How about RPSL, and published in the IRR? For that matter, people have been asking for ARIN to publish a list showing the minimum allocations made out of each ARIN block of addresses; this should be a reasonably straightforward set of RPSL policies. Lee > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Michael.Dillon at radianz.com > Sent: Friday, April 15, 2005 12:33 PM > To: ppml at arin.net > Subject: RE: [ppml] comments on 2004-8 > > > > 4. Announcement of IANA Allocations > > The IANA, the NRO, and the RIRs will make announcements and > update their > > > respective web sites regarding an allocation made by the IANA to an > > RIR. ICANN and the NRO will establish administrative procedures to > > manage this > process. > > If we are going to be making modifications to this one, > then I think it is time to say that these announcements > and web accessible documents should be in a machine-parseable > format. Something like RSS could be used or even just a plain > XML page. The current IANA list of address ranges is not > machine parseable and is not consistent from range to range. > There is no good reason why the list of ranges produced by > IANA should be broken (or aggregated) on class A boundaries. > If they have this info in a database, then it should be > trivial to report it as an XML file. > > --Michael Dillon > From marla_azinger at eli.net Fri Apr 15 12:53:41 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 15 Apr 2005 09:53:41 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul Message-ID: <10ECB7F03C568F48B9213EF9E7F790D209B122@wava00s2ke2k01.corp.pvt> In addition to Glenn's concerns and the two I wrote below I can not support this proposal as written. More Concerns: 1. I feel it would be best for us to get a definative answer on Privacy Laws and what should and should not be made public accesible information. Along with a definition of what "public Accessible" really entails. This proposal doesn't require you to publish anything publically so hypothetically it could never be at odds with any privacy law. However, the burden moves back to the ISP to insure that they are in compliance with the law with respect to their customers. This might be hard for ISP's that span the US and more. Should'nt we make a policy that applies the same to everyone? This proposal provides "choice". But is that really a healthy policy? Giving someone the choice would create division between companies that make information "secure" and companies that don't. This could create an unfair market advantage. If we were to choose a policy that enforces security I would hope that it still requires publication but that the publication is secured. Not information horded away to keep it secure. I'm not sure if this is possible...but it is another way of doing security that should be reviewed. I'm sure there are many other ways of securing information that can be reviewed as well. We should give it the diligence it requires and review as many different ways possible that we can keep information secure. We shouldn't just approve the first solution at hand which is to "hide the information from everyone". 2. Nothing is perfect. If someone doesnt want to take the path of contacting the downstream provider first because they dont trust that the information is correct...then so be it. No one is stopping them from going straight to the uppstream provider first. With current policy...the CHOICE YOU HAVE is to choose which contact info you want to pursue. Why should we take this choice away? LIke I said, nothing is perfect and there will be invalid emails here and there, but its not hurting anyone having them in the system. If we move this proposal forward and change what "CHOICE" people have to make then here's what happens: If you don't publish this information then your company will end up answering all first line abuse complaints. Which is ok if you are a big company and have at least 5 people working for your abuse team. However, if you are a small company and you can only have 1 person on your abuse team then they are going to need to publish this information so that their customers can respond themselves to first line abuse complaints. If it becomes a choice to publish information or not.....then the small companies that have to publish this information in order to keep the headcount cost down within their abuse team ...will end up facing the loss of customers to the bigger companies that can afford to not publish this information and have large headcount in the abuse team. Bad data is worse than no data doesn't hold here. Why would someone publish bad data when they want their customers to be answering to first line abuse complaints? In my opinion the worst kind of bad data I see is when I got to search who a /24 is assigned to and the only record on hand is that of the large ISP and not who is actually claiming to be using it. Marla Azinger Electric Lightwave -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Glenn Wiltse Sent: Friday, April 15, 2005 7:34 AM To: Member Services Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2005-2: Directory Services Overhaul I've got ALOT of concerns about this proposal. More then I do with 2005-3. Ed Lewis rasied several good points that I too am concerned about relating to this proposal. Many of these terms such as SUSPEND, reclaim, offenders, or even non-responsive, don't seem to be defined very well if at all. The problems I have with this proposal are too numerous to go into in every detail right now. Let me just ask about 'reclaim' a resource... Does that mean if a ISP should assign a /24 to a customer, and that customer should commit these 'offenses', do you then reclaim a whole /14 or larger resorce that the /24 is part of? Aside from these concerns... If ARIN staff don't have time to track down 'lame delegation' offenders... how are they ever going to tackle this job being proposed here? This is potentialy a HUGE amount of work for ARIN and for ISPs with large amounts of re-assignment information. I think this is way too agressive of a aproach. I will not support this proposal as written. Glenn Wiltse On Wed, 9 Mar 2005, 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. > > 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. > > > > !DSPAM:422f689b17078253968004! > > > From Ed.Lewis at neustar.biz Fri Apr 15 14:39:30 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 15 Apr 2005 14:39:30 -0400 Subject: [ppml] comments on 2004-8 In-Reply-To: References: Message-ID: At 17:33 +0100 4/15/05, Michael.Dillon at radianz.com wrote: >> 4. Announcement of IANA Allocations >> The IANA, the NRO, and the RIRs will make announcements and update their > >> respective web sites regarding an allocation made by the IANA to an RIR. >> ICANN >> and the NRO will establish administrative procedures to manage this >process. > >If we are going to be making modifications to this one, >then I think it is time to say that these announcements >and web accessible documents should be in a machine-parseable >format. Something like RSS could be used or even just a plain >XML page. The current IANA list of address ranges is not >machine parseable and is not consistent from range to range. >There is no good reason why the list of ranges produced by >IANA should be broken (or aggregated) on class A boundaries. >If they have this info in a database, then it should be >trivial to report it as an XML file. As far as policy is concerned, I don't think that the details of the formatting, etc., are that important. I'd say that it is covered in the "will establish administrative procedures" phrase. (My comments are related to the flow of the announcements, not the contents of the announcements.) IANA's choice of data format isn't an ARIN problem, so I wouldn't attach that to this proposal in this arena. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From bicknell at ufp.org Fri Apr 15 14:57:04 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Apr 2005 14:57:04 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D209B122@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D209B122@wava00s2ke2k01.corp.pvt> Message-ID: <20050415185704.GA95722@ussenterprise.ufp.org> In a message written on Fri, Apr 15, 2005 at 09:53:41AM -0700, Azinger, Marla wrote: > 1. I feel it would be best for us to get a definative answer on > Privacy Laws and what should and should not be made public accesible > information. Along with a definition of what "public Accessible" > really entails. I've talked to ARIN Council and to a number of other people about "privacy laws" and the answer is that the problem is almost intractable. There are literally several hundred federal laws that deal with privacy in various circumstances, and if you throw in the state, province, and city laws you could realistically be looking at over 10,000 or even over 100,000 laws affecting privacy inside the ARIN region. What's more, many of them are conditional on various other criteria. Examples include Canada, where you can't publish information without consent of the party who's information is being published, or the Children's Online Protection Act, which prevents you from publishing information on people under the age of 13, or under 18 without parents consent. Is it reasonable for ARIN to require an ISP to obtain consent in these cases? Is it reasonable to deny someone under the age of 13 IP addresses because they cannot have their information published? I started off investigating the legal aspects of this policy and quickly backed away. To say the legal side of things is a can of worms grossly understates the problem. Add to this that this is an area of law that's rapidly changing. Look at the recent identity thefts that have made the news. There are now over 100 bills pending in congress that all have provisions dealing with keeping "private information" "private". Since many of you work for companies with legal teams, what I would do is urge you to ask your own lawyers. Tell them ARIN currently requires you to publish your client's name, address, and e-mail address under certain circumstances, and you want to know if it is legal for your company to do so in your jurisdiction. I believe that the conversation that you have will be very interesting. -- 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 L.Howard at stanleyassociates.com Fri Apr 15 15:11:59 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 15 Apr 2005 15:11:59 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Azinger, Marla > Sent: Friday, April 15, 2005 12:54 PM > To: Glenn Wiltse; Member Services > Cc: ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2005-2: Directory > Services Overhaul > > > In addition to Glenn's concerns and the two I wrote below I > can not support this proposal as written. > > More Concerns: > > 1. I feel it would be best for us to get a definative answer > on Privacy Laws and what should and should not be made public > accesible information. Along with a definition of what > "public Accessible" really entails. I'm sure there will be a legal review. Isn't that part of the IRPEP? Ah, I see Leo's post now. > This proposal doesn't require you to publish anything > publically so hypothetically it could never be at odds with > any privacy law. However, the burden moves back to the ISP > to insure that they are in compliance with the law with > respect to their customers. This might be hard for ISP's > that span the US and more. > > Should'nt we make a policy that applies the same to everyone? If different jurisdiction have different requirements, we'll have a hard time with that. US law enforcement is pushing for mandatory publishing (according to NPR's Morning Edition), but Canadian law pushes toward anonymity. We're back to needing legal advice. > > This proposal provides "choice". But is that really a > healthy policy? Giving someone the choice would create > division between companies that make information "secure" and > companies that don't. I don't see anything about choice. Nothing here overrides the SWIP requirements. The Public database is the current WhoIs; the Confidential database is billing information. > In my opinion the worst kind of bad data I see is when I got > to search who a /24 is assigned to and the only record on > hand is that of the large ISP and not who is actually > claiming to be using it. In that case, the large ISP has made a business decision to be the first line of response for their customers. Many ISPs have determined that most of their customers are not equipped to handle abuse calls, and therefore offer response as a value-added service. However, there are some refinements I think are needed. . . I agree that the terms "suspended" and "reclaimed" are not clearly defined. ARIN's enforcement powers are roughly limited to a) removing WHOIS records, b) removing IN-ADDR records, C) removing IRR records. Section 3.3.1 isn't as tightly worded as it needs to be. The APID should be available to users who agree to ARIN's AUP, not just completing the form. Also, let's not limit the format; if it makes more sense to use DVD-ROM, Blu-Ray or cuneiform on clay tablets to publish the data, and if the requestor is willing to pay for the cost of the CD-RW, laser, or pallet trucks, that's between staff and the requestor. Could the requirements in 3.3.1.1 be in numberic order? (#3 is self-referential, to section 3.3.1, out of order with #2 which refers to #3 and #4 which refers to #2. Yes, that sentence was intentional.) We should not throw out old section 3.4, RE: Routing Registry. 3.5 could be a little tougher. . . ARIN should take every reasonable precaution to prevent unauthorized access to the ACID. Frankly, the industry standard for security isn't what it should be. I do support this policy in substance, but it could use a round of editing. Lee > > > Marla Azinger > Electric Lightwave > > > > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > Behalf Of Glenn Wiltse > Sent: Friday, April 15, 2005 7:34 AM > To: Member Services > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2005-2: Directory > Services Overhaul > > > I've got ALOT of concerns about this proposal. More then I > do with 2005-3. Ed Lewis rasied several good points that I > too am concerned about relating to this proposal. Many of > these terms such as SUSPEND, reclaim, offenders, or even > non-responsive, don't seem to be defined very well if at all. > The problems I have with this proposal are too numerous to go > into in every detail right now. > > Let me just ask about 'reclaim' a resource... Does that mean > if a ISP should assign a /24 to a customer, and that customer > should commit these 'offenses', do you then reclaim a whole > /14 or larger resorce that the /24 is part of? > > Aside from these concerns... If ARIN staff don't have time > to track down 'lame delegation' offenders... how are they > ever going to tackle this job being proposed here? This is > potentialy a HUGE amount of work for ARIN and for ISPs with > large amounts of re-assignment information. I think this is > way too agressive of a aproach. > > I will not support this proposal as written. > > Glenn Wiltse > > On Wed, 9 Mar 2005, 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. > > > > 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. > > > > > > > > !DSPAM:422f689b17078253968004! > > > > > > > From bicknell at ufp.org Fri Apr 15 15:23:06 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Apr 2005 15:23:06 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: <422F66F3.3090606@arin.net> Message-ID: <20050415192306.GB95722@ussenterprise.ufp.org> In a message written on Fri, Apr 15, 2005 at 10:34:02AM -0400, Glenn Wiltse wrote: > I've got ALOT of concerns about this proposal. More then I do with > 2005-3. Ed Lewis rasied several good points that I too am concerned about > relating to this proposal. Many of these terms such as SUSPEND, reclaim, > offenders, or even non-responsive, don't seem to be defined very well if > at all. The problems I have with this proposal are too numerous to go into > in every detail right now. They are not defined in the /policy/, which is not to say they are not defined. For instance with regards to "non-responsive", I quote: ] The ARIN staff shall publish the time thresholds and procedural ] details to implement this policy on the ARIN web site. So before ARIN staff can call someone non-responsive they must publish the procedure they will use to contact people, and the amount of time to repspond before considered non-responsive. The reason the methods and timeframes are not spelled out in the policy is rooted in ARIN's own history of such things. They never go as planned. Perhaps they start with e-mail, but find as they do it phone always works better. Perhaps they start out with 3 months, but find out that makes the workload too hard so it's better to go to 6 months. At the end of the day, what's important is that these are implementation details, not policy details. We don't want policies that say "ARIN Staff will call the listed phonenumber on the thrid tuesday of the month at 2:30PM to see if you answer." They don't work. So yes, non-responsive is not defined in this policy, but it must be defined and published by staff prior to the implementation of the policy, and may be modified from time to time by the staff as approproate without having to go through a 2+year policy cycle. Sticking the staff, and ARIN members with bad methods or timeframes for 2+ years because that's how long it takes to change a policy is not a good course of action. > Let me just ask about 'reclaim' a resource... Does that mean if a > ISP should assign a /24 to a customer, and that customer should commit > these 'offenses', do you then reclaim a whole /14 or larger resorce that > the /24 is part of? The policy allows for that possibility, however, in practice I don't see how it could ever occur. To get to a reclaim state, you have to go through the following steps: 1) Someone gets a resource. 2) ARIN attempts to verify the contact information. 3) Verification fails. 4) ARIN notifies the upstream. (Note, there is a branch here in the policy depending on if it is a verification problem with an ARIN allocation, or with suballocation information. I'm considering the suballocation case as you asked about the "/24 to a customer" version). 5) The upstream does not correct the problem in a reasonable amount of time. 6) The resource becomes suspended. 7) ARIN recontacts the upstream, asking them again to fix the problem. 8) The upstream does not correct the problem in a reasonable amount of time again. 9) The resource (eg, the /14) can be reclaimed. Now, for #5 and #8, the upstream has several choices to correct the problem. First, they can update the name/address/phone/e-mail that is wrong. Since this is a customer I see no reason why the ISP wouldn't have that information, after all they are probably billing the person. Second, if that's too hard for some reason under this policy they can simply remove the record. No record is required (publically viewable), so no record is ok. No record, no bad info, problem corrected. Given both of these corrections are boardline trivial, and the upstream gets two shots with a "reasonable amount of time" (which I would think would be some number of weeks) to make the fixes, I don't really see how it could ever happen. However, an interesting case is the company that goes belly up completely, closing the doors never to be heard from again. In that case it might get there, and ARIN would be right to reclaim the resource. > Aside from these concerns... If ARIN staff don't have time to track down > 'lame delegation' offenders... how are they ever going to tackle this job > being proposed here? This is potentialy a HUGE amount of work for ARIN and > for ISPs with large amounts of re-assignment information. I think this is > way too agressive of a aproach. Well, first, we don't have the ARIN staff impact analysis, something I am eager to see myself. They do have some experience in this area (mainly from the lame delegation work) so their estimates will be very interesting. As for how "agressive" it is, I'm not sure how you can make that statement. There's no timeline in this document, specifically so if does take a lot of man hours they can set a verification time of "once a year" or similarly long time to reduce the workload. There's no requirement this happen once a week, or even anything approching "frequently". In terms of wasting staff time, I'm more concerned right now that we're spending man hours on both ARIN's side and the ISP's side to enter data that is worthless. That's the real waste. It's not hard to find thousands of records which are no good. While getting over the hump and removing the old data is going to be a huge amount of work, waiting will only make that task larger later as we're still adding to the mess. Once the data is cleaned up, the overall work load for ARIN staff and for customers should be significantly reduced. -- 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 william at elan.net Fri Apr 15 15:24:39 2005 From: william at elan.net (william(at)elan.net) Date: Fri, 15 Apr 2005 12:24:39 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <20050415185704.GA95722@ussenterprise.ufp.org> References: <10ECB7F03C568F48B9213EF9E7F790D209B122@wava00s2ke2k01.corp.pvt> <20050415185704.GA95722@ussenterprise.ufp.org> Message-ID: On Fri, 15 Apr 2005, Leo Bicknell wrote: > In a message written on Fri, Apr 15, 2005 at 09:53:41AM -0700, Azinger, Marla wrote: >> 1. I feel it would be best for us to get a definative answer on >> Privacy Laws and what should and should not be made public accesible >> information. Along with a definition of what "public Accessible" >> really entails. > > I've talked to ARIN Council and to a number of other people about > "privacy laws" and the answer is that the problem is almost > intractable. > > There are literally several hundred federal laws that deal with > privacy in various circumstances, and if you throw in the state, > province, and city laws you could realistically be looking at over > 10,000 or even over 100,000 laws affecting privacy inside the ARIN > region. And every one of those laws deals with INDIVIDUAL privacy rights, not those of corporate or business identity. If anything the trend is that information on what public resources companies use should be made public with easier access to such data. Note that we already have policies right now in ARIN region that DO NOT require publishing personal name as contact (ISP can always choose to use their own contacts and simple reassignment does not require publishing contacts either) and that allow to not withhold individual name or address when type of access is residential. As such I think current ARIN policies already give ISPs the leverage to comply with existing laws. Where as the new policies if approved would restrict access to information on use what most consider public resources by commercial entities and severally restrict research that can be conducted on the use of these resources. > What's more, many of them are conditional on various other > criteria. Examples include Canada, where you can't publish information > without consent of the party who's information is being published, > or the Children's Online Protection Act, which prevents you from > publishing information on people under the age of 13, or under 18 > without parents consent. Is it reasonable for ARIN to require an > ISP to obtain consent in these cases? Is it reasonable to deny > someone under the age of 13 IP addresses because they cannot have > their information published? Current residential privacy policy would allow to withheld the person's name. I would also note that under laws in US, the persons under 18 in US (16 in Canada) can not enter into legal agreement (except with consent of their guardian) so I find it unlikely that it strange how under these circumstances they can become customers of the ISP (and I'm pretty sure no ISP would want 13 year old as a customer without parent's consent). > I started off investigating the legal aspects of this policy and > quickly backed away. To say the legal side of things is a can of > worms grossly understates the problem. Add to this that this is > an area of law that's rapidly changing. Look at the recent identity > thefts that have made the news. There are now over 100 bills pending > in congress that all have provisions dealing with keeping "private > information" "private". Yes and all of them deal with what is already private data that some companies keep in their database and want to insure such data is protected. Such data is not part of current public whois database (social security numbers, credit cards, etc) but ARIN does keep some of this info in their private database and so such laws would apply to ARIN if they pass and require ARIN to keep this info more secure. By classifying majority of what is currently public ARIN data as private, you may well cause additional expenses on arin if it has to keep safe (by standards of new laws that may pass) a lot larger part of their database. > Since many of you work for companies with legal teams, what I would > do is urge you to ask your own lawyers. Tell them ARIN currently > requires you to publish your client's name, address, and e-mail > address under certain circumstances Again see above as to that if the client is a person with what can be classified as consumer access, then none of the information need to be public made public. In other circumstances only client's name and address need to be made public but email address IS NOT require to be made public (unless this client is listed as contact for ip block, but there is no requirement for ISP to do that). > legal for your company to do so in your jurisdiction. I believe > that the conversation that you have will be very interesting. And most likely after they fully examine current ARIN policies and understand clarification that I've just made, they will find that there is no serious problem. -- William Leibzon Elan Networks william at elan.net From william at elan.net Fri Apr 15 15:29:25 2005 From: william at elan.net (william(at)elan.net) Date: Fri, 15 Apr 2005 12:29:25 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: Message-ID: On Fri, 15 Apr 2005, Howard, W. Lee wrote: >> This proposal provides "choice". But is that really a >> healthy policy? Giving someone the choice would create >> division between companies that make information "secure" and >> companies that don't. > > I don't see anything about choice. Nothing here overrides the > SWIP requirements. The Public database is the current WhoIs; > the Confidential database is billing information. If you read policy proposal carefully you will see that it makes changes and requirements and SWIP is no longer required to be in public database but is still required to be in private ARIN database. -- William Leibzon Elan Networks william at elan.net From bicknell at ufp.org Fri Apr 15 15:41:12 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Apr 2005 15:41:12 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: Message-ID: <20050415194112.GC95722@ussenterprise.ufp.org> In a message written on Fri, Apr 15, 2005 at 03:11:59PM -0400, Howard, W. Lee wrote: > I don't see anything about choice. Nothing here overrides the > SWIP requirements. The Public database is the current WhoIs; > the Confidential database is billing information. I want to be clear about this, because this is an area of controversey in the policy as proposed. SWIP requires do not change. You must submit SWIPs under the new policy for the same items that you submit SWIPs now. However, a SWIP can be marked "publish" or "don't publish". That is, you have a choice to not have the SWIP show up in whois/bulkwhois/the web query. In that case verification does not apply to the record, and the parent record would be the only thing that appears for a general lookup. > I agree that the terms "suspended" and "reclaimed" are not > clearly defined. ARIN's enforcement powers are roughly > limited to a) removing WHOIS records, b) removing IN-ADDR > records, C) removing IRR records. Suspended is simply a flag. "You passed this point." I'm not sure what more there is to define. The policy states which steps need to be taken to reach a suspended state, which is simply a flag in the database, and the ability for the ARIN staff to proceed to the next step. Similarly "reclaim" to me is exactly what it says it is. It's a return to the pre-allocation state. I would assume that includes removing whois, in-addr.arpa mappings, and putting it back in the available pool to be reallocated in the future. But again, the individual steps are procedural, not policy. The ARIN staff would have to publish the procedure before any of these steps could be done, so the exact enumeration would be available prior to any enforcement. > Section 3.3.1 isn't as tightly worded as it needs to be. > The APID should be available to users who agree to ARIN's > AUP, not just completing the form. Also, let's not limit > the format; if it makes more sense to use DVD-ROM, Blu-Ray > or cuneiform on clay tablets to publish the data, and if > the requestor is willing to pay for the cost of the CD-RW, > laser, or pallet trucks, that's between staff and the > requestor. You know, it wasn't my intention to have a closed list. I realize now that is not clear, as you are the first person to bring that to my attention. Rather, it was to have a list of methods that would be required to be supported, but to allow staff to work out other arrangements as appropriate. Somehow I forgot to add that before the proposal went in. It's probably too late to add that for this go round, but the policy as written is no worse in that respect than the one we have today. > Could the requirements in 3.3.1.1 be in numberic order? > (#3 is self-referential, to section 3.3.1, out of order > with #2 which refers to #3 and #4 which refers to #2. > Yes, that sentence was intentional.) Ha. I think that's a formatting change we can make at this point (or rather, the AC could make if the policy passes) and does make some sense. > We should not throw out old section 3.4, RE: Routing Registry. We don't. If you look at the bottom it gets renumbered to 3.7, and inserted verbatem. > 3.5 could be a little tougher. . . ARIN should take every > reasonable precaution to prevent unauthorized access to the > ACID. Frankly, the industry standard for security isn't > what it should be. When this was crafted, "industry standard" was seen as good enough. My how times change quick. :) -- 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 bicknell at ufp.org Fri Apr 15 15:50:53 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Apr 2005 15:50:53 -0400 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D209B11B@wava00s2ke2k01.corp.pvt> Message-ID: <20050415195053.GD95722@ussenterprise.ufp.org> In a message written on Thu, Apr 14, 2005 at 02:17:01PM -0400, Edward Lewis wrote: > Well, this is a topic I would like to see discussed in a > technically-bent arena. One solution, which causes the least amount > of liability concerns (see above) is to retain all delegations > wherein one delegation is healthy. This could be categorized as > "getting the low hanging fruit." Not complete, but better than > nothing at all. Consider the following case: Member is delegated a /16 by ARIN. Member correctly configures a /16 on their nameserver. Member delegates a /24 to a customer. The customer is lame for that /24. In this case all the "bad resolvers" out there will follow good delegations to the members nameservers, and then repeatedly beat on them over the lame delegation. So we've moved the problem from the root nameservers (a public resource arin is tangentally interested in) to the members nameservers, which if the member wants to not fix their customers issue and simply build them big enough to take it that's their issue. So I don't know that there's any value in ARIN looking at things other than direct references from ARIN's nameservers. [Note: If you don't choose tidy /16 and /24 boundaries arin my directly point to a subcustomer, in which case ARIN may still be interested. I chose the easy case for discussion purposes.] -- 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 Ed.Lewis at neustar.biz Fri Apr 15 15:56:45 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 15 Apr 2005 15:56:45 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <20050415194112.GC95722@ussenterprise.ufp.org> References: <20050415194112.GC95722@ussenterprise.ufp.org> Message-ID: At 15:41 -0400 4/15/05, Leo Bicknell wrote: >Suspended is simply a flag. "You passed this point." I'm not sure >what more there is to define. The policy states which steps need >to be taken to reach a suspended state, which is simply a flag in >the database, and the ability for the ARIN staff to proceed to the >next step. What are the consequences of being suspended? Just a note in the database? Restrictions from getting more address space? Restrictions in editing the database (like adding nameservers, POC's)? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From bicknell at ufp.org Fri Apr 15 16:03:22 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Apr 2005 16:03:22 -0400 Subject: [ppml] comments on 2005-2 In-Reply-To: References: Message-ID: <20050415200322.GE95722@ussenterprise.ufp.org> In a message written on Thu, Apr 14, 2005 at 11:12:13AM -0400, Edward Lewis wrote: > Is "suspended" defined elsewhere? I searched the policy guide and > don't see the word. As I said to a previous poster, it's just a label. A flag that a particular step in the process has been passed. I suppose we could add a definition, but it would be "someone who has failed the first round of contacting is classified as suspended". > # 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. > > "Offenders" - this seems to be an inappropriate label. There is no > definition of the "offense." If we replaced "Offenders" with "Resource holders" is it acceptable? The "offense" was failure to respond, which I agree was poorly implied. > # 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. > > It would seem to me that ARIN never should respond to third party > reports in the spirit of confidentiality. There is no need to have > the policy to allow for ignoring "crying wolf." The worst that could > happen is that if org A repeatedly says org B is "down" and ARIN > either takes no steps to fix this OR is unable to fix this, org A > might go to NANOG and whine. (That'll happen anyway.) I disagree. Let's say an ISP lists a phone number, and it's disconnected. I should be able to e-mail ARIN and say "I tried to call ISP xyz and their phone is disconnected, so their contact information is invalid." Under the proposal ARIN would be required to put them in the queue for verification to see if the information can be updated. That's far more useful than finding the disconnected number but simply having to wait a week/month/year for ARIN to naturally re-verify them. There's no confidentiality disclosure there. ARIN is providing no information back to the reporter. All I wanted to do was give staff an out so if someone tried to get an ISP reverified once a day just to be a PITA ARIN staff could just ignore that person. > # 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 want so see IRIS on this list. The definition of IRIS for address > registries has been lagging, I'd like to see it get pushed through > the IETF and then deployed. With it, better authorization policies > can be implemented - regarding what data is widely public and what > data is available only to the registrant, etc. (If IRIS isn't > beneficial, I'd like to know why.) I have no objection to IRIS, and indeed would like to see it added. That said, I think it's probably too late to consider IRIS for this meeeting. If the proposal passes, we can present one at the next meeting to add IRIS to the list. -- 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 bicknell at ufp.org Fri Apr 15 16:07:33 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Apr 2005 16:07:33 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: <20050415194112.GC95722@ussenterprise.ufp.org> Message-ID: <20050415200733.GF95722@ussenterprise.ufp.org> In a message written on Fri, Apr 15, 2005 at 03:56:45PM -0400, Edward Lewis wrote: > What are the consequences of being suspended? Just a note in the > database? Restrictions from getting more address space? > Restrictions in editing the database (like adding nameservers, POC's)? Under the current proposal there are no consequences. Originally there was a thought to make it impossible to get more address space if you were suspended, but that seemed overly complex. So while that does not appear in the policy I've proposed, having the defined point to insert something like that later was left. I also don't particularly care one way or another if "SUSPENDED" is published. That to me is an implementation detail for staff. If they find it useful to publish that fact in whois so people know when they have failed the first round of verification, that's great. If it's just a checkmark in their procedure that the entity has failed the first round and no one else ever sees it, that's good too. Something for staff to clarify in the procedures, if this passes. -- 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 Ed.Lewis at neustar.biz Fri Apr 15 16:10:41 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 15 Apr 2005 16:10:41 -0400 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <20050415195053.GD95722@ussenterprise.ufp.org> References: <10ECB7F03C568F48B9213EF9E7F790D209B11B@wava00s2ke2k01.corp.pvt> <20050415195053.GD95722@ussenterprise.ufp.org> Message-ID: At 15:50 -0400 4/15/05, Leo Bicknell wrote: >So I don't know that there's any value in ARIN looking at things other >than direct references from ARIN's nameservers. There isn't any value. Please see http://www.arin.net/mailing_lists/ppml/3246.html for a previous discussion on this. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Fri Apr 15 16:27:18 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 15 Apr 2005 16:27:18 -0400 Subject: [ppml] comments on 2005-2 In-Reply-To: <20050415200322.GE95722@ussenterprise.ufp.org> References: <20050415200322.GE95722@ussenterprise.ufp.org> Message-ID: At 16:03 -0400 4/15/05, Leo Bicknell wrote: >As I said to a previous poster, it's just a label. A flag that a >particular step in the process has been passed. I suppose we could >add a definition, but it would be "someone who has failed the first >round of contacting is classified as suspended". Then don't use the word "suspended," perhaps "labeled" (or "marked," or "noted as unresponsive"). Suspended has connotes restrictions are put in place. ("Suspended license.") >If we replaced "Offenders" with "Resource holders" is it acceptable? The >"offense" was failure to respond, which I agree was poorly implied. Or registrant...what ever is appropriate. The term "offender" made me go back and look for the definition of the offense. >I disagree. Let's say an ISP lists a phone number, and it's >disconnected. I should be able to e-mail ARIN and say "I tried to >call ISP xyz and their phone is disconnected, so their contact >information is invalid." Under the proposal ARIN would be required >to put them in the queue for verification to see if the information >can be updated. That's far more useful than finding the disconnected >number but simply having to wait a week/month/year for ARIN to naturally >re-verify them. > >There's no confidentiality disclosure there. ARIN is providing no >information back to the reporter. All I wanted to do was give staff >an out so if someone tried to get an ISP reverified once a day just >to be a PITA ARIN staff could just ignore that person. The context of my comment is that the policy states: # 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. If ARIN does not respond to the party reporting, what does it matter if ARIN (staff?) chooses to ignore a reporting party that is known for "crying wolf?" I.e., I am questioning the need for the quoted paragraph. >I have no objection to IRIS, and indeed would like to see it added. >That said, I think it's probably too late to consider IRIS for this >meeting. If the proposal passes, we can present one at the next >meeting to add IRIS to the list. At what point is it too late? I asked about adding IRIS in this message a month ago: http://www.arin.net/mailing_lists/ppml/3201.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Apr 15 16:46:37 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Apr 2005 13:46:37 -0700 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: Message-ID: <2147483647.1113572797@imac-en0.delong.sj.ca.us> > No, at the end of the day it does not. Today it does, but > we are making an IPv6 policy that should last for many years. > I don't expect router design to stand still during that time > and I also don't expect any router vendors to reveal what > they are working on in their research labs. At the end of > the day, it is possible to optimize by processing fewer bits > and we should not remove that option from the table by > making bad policy and introducing yet another class of > IPv6 address. > No. We should, today, make policy based on our best knowledge of the facts today and our reasonable expectations of the future. Your theory of where routers might go is not what we should base policy on. Are you involved in router design or development? There is a policy process to allow us to change policy in the future if needs change. Since these addresses can be reclaimed and/or renumbered based on annual renewal and expiration, this creates a maximum 2 year lag between new policy and conversion. Again, having talked to some ASIC designers and a few people I know who code for FPGAs, they say that there is little to no difference in efficiency between sorting a sparsely populated 64 bit table and a sparsely or densly populated 32 bit table. They also state that lookups are not significantly less efficient. Yes, at the micro-level, there is some small difference in speed, but, not enough to be worth the tradeoff, especially if they have to handle exceptions for longer prefixes anyway. >> Given that 64k subnets is >> enough for most and that allocations made using RFC3531 will extend the >> initial /48 to a /47 for the few large organizations that require it, I >> don't see any advantages in giving /32s away to sites. > > If an organisation has an AS number then their network is not > a "site". > This is an utterly invalid assertion. I know several organizations that have ASNs which are single sites, and, a few which have multiple sites each of which is a separate AS. There is nothing in policy which says you cannot be a single site and get an AS. You can multihome a site. If you multihome, you are entitled to an AS. 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 Fri Apr 15 17:02:37 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Apr 2005 14:02:37 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: <422F66F3.3090606@arin.net> Message-ID: <2147483647.1113573757@imac-en0.delong.sj.ca.us> > Let me just ask about 'reclaim' a resource... Does that mean if a > ISP should assign a /24 to a customer, and that customer should commit > these 'offenses', do you then reclaim a whole /14 or larger resorce that > the /24 is part of? Everyone, Please, understand that ALL ARIN policies apply to resources allocated or assigned by ARIN directly to an ORGANIZATION which has signed an ARIN Registration Services Agreement. If the ORGANIZATION to which ARIN has allocated or assigned the superset resource works in good faith with ARIN to resolve the issue and maintains contact with ARIN, there is no issue. If the ORGANIZATION to which ARIN has allocated or assigned the superset resource is unresponsive, then, it is in the best interests of the community for ARIN to suspend IN-ADDR delegation for the smallest feasible portion (e.g. /24 or multiple /24s) of the resource which is known to be a LAME delegation. There is no reason to believe that an ISP is going to lose their /14 because a /24 within it is broken. This is unrealistic overreaching. However, if a /28 is delegated lamely, and ARIN cannot reach the upstream ARIN subscriber, then, ARIN would, IMHO, be right to suspend IN-ADDR service for the relevant /24. Eventually, the upstream subscriber will either respond (in the form of renewal) or ARIN should reclaim the resource anyway. 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 Fri Apr 15 17:02:18 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 15 Apr 2005 17:02:18 -0400 Subject: [ppml] comments on 2005-2 In-Reply-To: <42602768.5050309@readytechs.com> References: <20050415200322.GE95722@ussenterprise.ufp.org> <42602768.5050309@readytechs.com> Message-ID: At 16:43 -0400 4/15/05, Bill Van Emburg wrote: >Edward Lewis wrote: >> At 16:03 -0400 4/15/05, Leo Bicknell wrote: >> >As I said to a previous poster, it's just a label. A flag that a >> >particular step in the process has been passed. I suppose we could >> >add a definition, but it would be "someone who has failed the first >> >round of contacting is classified as suspended". >> Then don't use the word "suspended," perhaps "labeled" (or >>"marked," or "noted as unresponsive"). Suspended has connotes >>restrictions are put in place. ("Suspended license.") >> >I feel strongly that "suspended" *should* be the language, and should mean >something. There is no reason ARIN can't deny future resources to someone >who's suspended; turn off their reverse DNS delegations; or even reclaim >the space. I'll put it this way... Upon first contact by ARIN staff of a reportedly unresponsive contact, the contact is marked as "being researched/investigated/verified". Because the contact might be a postal address, you have to allow for some latency in the testing - even email is not necessarily immediate. Once a contact has failed to respond in an appropriate window of time, the contact is noted as non-responsive and some actions are taken. If all contacts for a resource are marked as non-responsive, then the label of "suspended" comes into play. Two kinds of suspension can exist - suspension from automatic updates to the database (to suppress the chance of hijacking the resource) and suspension "warnings" to the routing community. You can divide the problem into suspending a POC object (no cert, no changes, no more space) and suspending a resource (it shouldn't be routed, no reverse DNS). (Reclaiming space is more drastic than suspending it. Neither space should be allowed to be used, but reclaimed space is no longer "reserved" for the original purpose.) Note - having ARIN police the routing tables is not what I mean. What I mean by the latter is that the only meaningful suspension of a resource is to make it's use "illegal". (Like a suspended drivers license.) So - in the interim of testing the contact, I think you don't mark the contact as "suspended." (Innocent until proven guilty and all that.) Once the contact is a problem, appropriate penalties should apply. Keep in mind that testing contacts have to deal with the reality of time. And that for a network resource, there may be multiple contacts. So - I think that suspended isn't the right word for initial reports of non-responsive, but suspended with teeth is the right word for resources with no responding contacts. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From L.Howard at stanleyassociates.com Fri Apr 15 17:17:31 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 15 Apr 2005 17:17:31 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Leo Bicknell > Sent: Friday, April 15, 2005 3:41 PM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2005-2: Directory > Services Overhaul > > > In a message written on Fri, Apr 15, 2005 at 03:11:59PM > -0400, Howard, W. Lee wrote: > > I don't see anything about choice. Nothing here overrides the SWIP > > requirements. The Public database is the current WhoIs; the > > Confidential database is billing information. > > I want to be clear about this, because this is an area of > controversey in the policy as proposed. > > SWIP requires do not change. You must submit SWIPs under the > new policy for the same items that you submit SWIPs now. > However, a SWIP can be marked "publish" or "don't publish". > That is, you have a choice to not have the SWIP show up in > whois/bulkwhois/the web query. In that case verification > does not apply to the record, and the parent record would be > the only thing that appears for a general lookup. OK, I stand corrected on the intent. And somehow I completely missed all proposed text after proposed 3.6, which explains why my reply to Marla made no sense. Stet: 4.2.3.7.2. /29s and larger nets - ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data using the format described in section 4.2.3.7.5. This: 4.2.3.7.4. Visible via WHOIS - This information must be visible via WHOIS prior to submitting a request for a new allocation. For further information on reassigning IP address space, please see RFC 2050. gets replaced with: All reassignment information for current blocks shall be submitted to ARIN prior to submitting a request for a new allocation. It sounds like an ISP may choose to publish, and may then choose to publish locally (maintaining public availability 24x7), and may also choose to gouge out their eyes with hot pokers. For clarification, is section 3.3.3 Requirements for Internet Accessible Services a set of requirements of ARIN, or of organizations? Passive voice makes it a little unclear. > Suspended is simply a flag. "You passed this point." A Boolean value with no defined use. ACK. > Similarly "reclaim" to me is exactly what it says it is. > It's a return to the pre-allocation state. I would assume > that includes removing whois, in-addr.arpa mappings, and > putting it back in the available pool to be reallocated in the future. > > But again, the individual steps are procedural, not policy. > The ARIN staff would have to publish the procedure before any > of these steps could be done, so the exact enumeration would > be available prior to any enforcement. In general, I agree with you. In the case of reclamation, I think it should be spelled out, here in the policy, precisely what happens to you. > > > [list of ways to provide bulk WHOIS] > > You know, it wasn't my intention to have a closed list. I > realize now that is not clear, as you are the first person to > bring that to my attention. Rather, it was to have a list of > methods that would be required to be supported, but to allow > staff to work out other arrangements as appropriate. Somehow > I forgot to add that before the proposal went in. It's > probably too late to add that for this go round, but the > policy as written is no worse in that respect than the one we > have today. I think the AC could add that in review, since it is not a substantive change, or at least, is consistent with the spirit of the proposed policy. Thanks for setting me straight on where this policy was going. Lee > -- > 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 Is it just me, or is all of their best work going into TV theme shows and children's music? Oh, I guess that's off-topic for the list. From owen at delong.com Fri Apr 15 17:22:11 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Apr 2005 14:22:11 -0700 Subject: [ppml] 2005-1 and/or Multi6 In-Reply-To: References: Message-ID: <2147483647.1113574931@imac-en0.delong.sj.ca.us> Michael, Similarly, if there is an advantage to processing 64 bit table entries or 128 bit table entries, said variable hardware will be programmed in such a way as to optimize these facts. Your own argument defeats itself. Trying to drive policy into insanely large allocations for multihomed organizations that may be no larger than a dorm room by using the potential for where FPGAs might eventually go some time in the future is specious at best. Owen -------------- 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 Fri Apr 15 17:40:01 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Apr 2005 14:40:01 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D209B122@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D209B122@wava00s2ke2k01.corp.pvt> Message-ID: <2147483647.1113576001@imac-en0.delong.sj.ca.us> > 1. I feel it would be best for us to get a definative answer on Privacy > Laws and what should and should not be made public accesible information. > Along with a definition of what "public Accessible" really entails. > I think not. Especially in terms of state-to-state differences, and, the diffferences between privacy laws in Canada and the US, it just doesn't make sense. The ISPs are in a business which requires them to comply with the privacy laws in the areas in which they do business. This is part of the requirements of the business they are in, and, they already shoulder this responsibility. They should, therefore, be able to make their contributions to the whois database on this basis. Perhaps ARIN should include an out in the policy language of: In the case where an ISP can show that appropriate submission/publication of data required under this policy would violate a law, the ISP shall not make such submission/publication, and, shall provide the data to ARIN under seal accompanied by text of or reference to the applicable law. > This proposal doesn't require you to publish anything publicly so > hypothetically it could never be at odds with any privacy law. However, > the burden moves back to the ISP to insure that they are in compliance > with the law with respect to their customers. This might be hard for > ISP's that span the US and more. > Right... see above. If it's hard for them, so what. It's part of the business they are in. > Should'nt we make a policy that applies the same to everyone? > This policy does apply the same to everyone. Everyone gets the same choice. I don't see why this is a problem. > This proposal provides "choice". But is that really a healthy policy? > Giving someone the choice would create division between companies that > make information "secure" and companies that don't. This could create an > unfair market advantage. > That's called market differentiation, and, no, it's not an unfair market advantage, because, any advantage or disadvantage is based on the choice made by the management of said company. An unfair market advantage is when one company gets an advantage over another by virtue of some policy favorable to one and not favorable to the other set by an external body. Since all companies get the same set of choices, they may all choose the same policy, or, they may choose different policies, but, in any case, there is no unfair advantage because the other choices remain open to them. > If we were to choose a policy that enforces security I would hope that it > still requires publication but that the publication is secured. Not > information horded away to keep it secure. I'm not sure if this is > possible...but it is another way of doing security that should be > reviewed. I'm sure there are many other ways of securing information > that can be reviewed as well. We should give it the diligence it > requires and review as many different ways possible that we can keep > information secure. We shouldn't just approve the first solution at hand > which is to "hide the information from everyone". > Sorry, Marla, I can't even make sense of the above statement. If you want to publish information to the general public, then, you cannot secure it other than preventing write access. If you want to publish the information only to a subset of authenticatable users, then, that is secured information. It's pretty binary. Not a lot of shades of gray there. > If we move this proposal forward and change what "CHOICE" people have to > make then here's what happens: > > If you don't publish this information then your company will end up > answering all first line abuse complaints. Which is ok if you are a big > company and have at least 5 people working for your abuse team. However, > if you are a small company and you can only have 1 person on your abuse > team then they are going to need to publish this information so that > their customers can respond themselves to first line abuse complaints. > Well... If you are a small company and those are the tradeoffs, then, perhaps this is not the correct choice for you. In any realm of choice, there are always tradeoffs. That's what choice is about. Businesses make choices all the time. That's called management. > If it becomes a choice to publish information or not.....then the small > companies that have to publish this information in order to keep the > headcount cost down within their abuse team ...will end up facing the > loss of customers to the bigger companies that can afford to not publish > this information and have large headcount in the abuse team. > I don't see this as really being the case. The smaller companies will not have as much address space subject to abuse, so, they will attract fewer abuse complaints. A small company that enforces its AUP effectively can run on a relatively small abuse department. In my experience, the larger an organization gets, the less likely it is to enforce its AUP effectively, so, in fact, larger organizations need non-linearly larger abuse departments to cope with this fact. In my experience, this leads to a slight reversal of what you describe above. I don't think that whether the information is published or not is a significant factor to the smaller organization. Failure to publish, OTOH, will certainly produce a significantly bigger burden on the larger organization. In that respect, I suppose this policy could provide slight market advantage to the smaller organizations, but, compared to the other market advantages that come with being a large organization, I think this advantage for the little guy is relatively small. As such, I don't think it is unfair. > Bad data is worse than no data doesn't hold here. Why would someone > publish bad data when they want their customers to be answering to first > line abuse complaints? > Because they don't know it's bad. > In my opinion the worst kind of bad data I see is when I got to search > who a /24 is assigned to and the only record on hand is that of the large > ISP and not who is actually claiming to be using it. > Nope... The worst kind of bad data is when I find who owns the /24 directly in whois and they don't really exist and their upstream has the same non- existant data for them. I haven't made up my mind about this policy yet. However, I think a lot of what is in it is a step in the right direction. 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 bicknell at ufp.org Fri Apr 15 17:45:36 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Apr 2005 17:45:36 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: Message-ID: <20050415214536.GA2012@ussenterprise.ufp.org> In a message written on Fri, Apr 15, 2005 at 05:17:31PM -0400, Howard, W. Lee wrote: > For clarification, is section 3.3.3 Requirements for Internet > Accessible Services a set of requirements of ARIN, or of organizations? > Passive voice makes it a little unclear. Yes. It's a requirement for whoever publishes the information. If you submit SWIP's and tell ARIN to publish the data, then it's an ARIN requirement. If you tell ARIN that you want to do rwhois, and you run an RWHOIS server, then it is a requirement for you. If CRISP comes along and you run a CRISP server, then it's a requirement for that. That's why it's generic. If you are the person running the service that publishes the information, then it must be published 24x7x365. This is in direct response to people running rwhois servers but turnning them off 364 days a year, and having them up only for the one day when ARIN pulls data. It's also a response to a lesser problem of people who have it up all the time, but ACL it to only allow ARIN's netblocks to query the server. It also applies to future methods. If we move all this to HTTP, or CRISP, or Gopher, or any other random protocol then it still needs to be 24x7x365. > In general, I agree with you. In the case of reclamation, I > think it should be spelled out, here in the policy, precisely > what happens to you. *nod* I'll take that under advisement. -- 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 owen at delong.com Fri Apr 15 17:46:50 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Apr 2005 14:46:50 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: Message-ID: <2147483647.1113576410@imac-en0.delong.sj.ca.us> > However, there are some refinements I think are needed. . . > > I agree that the terms "suspended" and "reclaimed" are not > clearly defined. ARIN's enforcement powers are roughly > limited to a) removing WHOIS records, b) removing IN-ADDR > records, C) removing IRR records. > You left off D) Assigning the address to someone else or announcing conflicting routes directly from ARIN. I'm not necessarily advocating either of these actions, but, I'm not necessarily opposing them either. Just pointing out that they are options which exist. > Section 3.3.1 isn't as tightly worded as it needs to be. > The APID should be available to users who agree to ARIN's > AUP, not just completing the form. Also, let's not limit > the format; if it makes more sense to use DVD-ROM, Blu-Ray > or cuneiform on clay tablets to publish the data, and if > the requestor is willing to pay for the cost of the CD-RW, > laser, or pallet trucks, that's between staff and the > requestor. > Agreed. > I do support this policy in substance, but it could use a > round of editing. > Agreed. Well said Lee. 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 L.Howard at stanleyassociates.com Fri Apr 15 17:57:36 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 15 Apr 2005 17:57:36 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Owen DeLong > Sent: Friday, April 15, 2005 5:03 PM > To: Glenn Wiltse; Member Services > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2005-2: Directory > Services Overhaul > > > > Let me just ask about 'reclaim' a resource... Does that > mean if a ISP > > should assign a /24 to a customer, and that customer should commit > > these 'offenses', do you then reclaim a whole /14 or larger resorce > > that the /24 is part of? > > There is no reason to believe that an ISP is going to > lose their /14 because a /24 within it is broken. This is > unrealistic overreaching. However, if a /28 is delegated > lamely, and ARIN cannot reach the upstream ARIN subscriber, > then, ARIN would, IMHO, be right to suspend IN-ADDR service > for the relevant /24. Eventually, the upstream subscriber > will either respond (in the form of renewal) or ARIN should > reclaim the resource anyway. Wouldn't that impose collateral damage on the other /28 delegees surrounding them? Lee > > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. > From owen at delong.com Fri Apr 15 17:59:07 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Apr 2005 14:59:07 -0700 Subject: [ppml] comments on 2005-2 In-Reply-To: References: <20050415200322.GE95722@ussenterprise.ufp.org> Message-ID: <2147483647.1113577147@imac-en0.delong.sj.ca.us> ># 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. > > > If ARIN does not respond to the party reporting, what does it matter if > ARIN (staff?) chooses to ignore a reporting party that is known for > "crying wolf?" > > > I.e., I am questioning the need for the quoted paragraph. Whether the third party knows it or not, the ARIN staff would still be required to do the full investigation on each wolf cry without this paragraph. That is the need for the paragraph. It provides an out for the staff to use discretion in ignoring such repeat complaints. Without it, policy requires them to evaluate each one even though the results for the complainer are the same either way. 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 Fri Apr 15 18:03:12 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Apr 2005 15:03:12 -0700 Subject: [ppml] comments on 2005-2 In-Reply-To: References: <20050415200322.GE95722@ussenterprise.ufp.org> <42602768.5050309@readytechs.com> Message-ID: <2147483647.1113577392@imac-en0.delong.sj.ca.us> Reclaimed space should be eligible for reallocation. Failure to do this is absurd. Owen -------------- 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 Fri Apr 15 18:09:01 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Apr 2005 15:09:01 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: Message-ID: <2147483647.1113577741@imac-en0.delong.sj.ca.us> >> There is no reason to believe that an ISP is going to >> lose their /14 because a /24 within it is broken. This is >> unrealistic overreaching. However, if a /28 is delegated >> lamely, and ARIN cannot reach the upstream ARIN subscriber, >> then, ARIN would, IMHO, be right to suspend IN-ADDR service >> for the relevant /24. Eventually, the upstream subscriber >> will either respond (in the form of renewal) or ARIN should >> reclaim the resource anyway. > > Wouldn't that impose collateral damage on the other /28 delegees > surrounding them? Yes, but, if their upstream is completely unresponsive to ARIN, that is the least of the collateral damage they can expect when their ISP starts having allocations reclaimed. Remember, this only happens if the ISP is non-responsive to ARIN, not the individual /28 holder. 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 william at elan.net Fri Apr 15 19:25:29 2005 From: william at elan.net (william(at)elan.net) Date: Fri, 15 Apr 2005 16:25:29 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <2147483647.1113577741@imac-en0.delong.sj.ca.us> References: <2147483647.1113577741@imac-en0.delong.sj.ca.us> Message-ID: On Fri, 15 Apr 2005, Owen DeLong wrote: >>> There is no reason to believe that an ISP is going to >>> lose their /14 because a /24 within it is broken. This is >>> unrealistic overreaching. However, if a /28 is delegated >>> lamely, and ARIN cannot reach the upstream ARIN subscriber, >>> then, ARIN would, IMHO, be right to suspend IN-ADDR service >>> for the relevant /24. Eventually, the upstream subscriber >>> will either respond (in the form of renewal) or ARIN should >>> reclaim the resource anyway. >> >> Wouldn't that impose collateral damage on the other /28 delegees >> surrounding them? > > Yes, but, if their upstream is completely unresponsive to ARIN, that > is the least of the collateral damage they can expect when their ISP > starts having allocations reclaimed. Remember, this only happens > if the ISP is non-responsive to ARIN, not the individual /28 holder. I think the way to clear out when network resource maybe suspended should be based on that all contacts listed for network resource are not responsive. I note that title of proposes section 3.2.1 is already "Non-Responsive Contacts", I believe this is good and section should be focused only on that and then we should have separate section (3.2.2) that details regarding when resource is considered invalid and what happens to thatresource then (i.e. that arin can choose to make resource as invalid, suspend IN-addr serves or completely remove resource from whois depending on how long the problem continues). Also as has been noted many times the biggest problem with privacy that people see is that their names are automatically listed for the resource without their permission. While current policies do not really require that, many ISPs do not know it and I think it should be clear that only contacts that agreed to have their name listed should be in the ARIN public database. If we focus on that you'll see that there is really no reason afterward (for privacy or similar reasons) to not be listing network blocks in public whois (and ISP have to send the blocks to ARIN anyway so it does not save anything in data storage or workload for either ISP or ARIN). As such I propose that section 3.2 be adjusted of proposed poolicy be adjusted as follows: ---------------------------------------------------------------------- 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. All contact information listed in APID should be made available with express permission of such contact and ARIN shall afterward from time-time verify this information and insure it 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 notify other contacts of the same organization in an atempt to reach contact being verified. If there is are no other contacts available and contact information remains unverified, ARIN should mark this contact as INVALID. Third parties may report the inability to make contact with a party via information in the APID. In this case ARIN shall attempt the perform 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. Contacts who fail to respond to third parties more than 4 times per month for three months may be listed as INVALID at the discretion of ARIN staff. If a third party source submits reports of the inability to make contact that are subsequently disproved, ARIN may choose to ignore reports from such source. 3.2.2 Suspension of Network Resources If for any network resource all contacts listed are INVALID, ARIN should 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 and IN-ADDR and other services for such resource shall no longer be made available. 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 maybe be reclaimed at the discretion of ARIN staff. 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. ---------------------------------------------------------------------- -- William Leibzon Elan Networks william at elan.net From randy at psg.com Sat Apr 16 01:32:46 2005 From: randy at psg.com (Randy Bush) Date: Fri, 15 Apr 2005 19:32:46 -1000 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: <10ECB7F03C568F48B9213EF9E7F790D209B122@wava00s2ke2k01.corp.pvt> Message-ID: <16992.41854.101656.205552@roam.psg.com> > 1. I feel it would be best for us to get a definative answer on > Privacy Laws and what should and should not be made public > accesible information. Along with a definition of what "public > Accessible" really entails. in which countries? randy From michel at arneill-py.sacramento.ca.us Sat Apr 16 02:23:23 2005 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 15 Apr 2005 23:23:23 -0700 Subject: [ppml] 2005-1 and/or Multi6 Message-ID: >>> Michael Dillon wrote: >>> At the end of the day, it is possible to optimize by >>> processing fewer bits >> Michel Py wrote: >> This would have been true in the past, but not anymore. By the >> time the size of the routing table is so big that it requires >> optimization, there will be no processor that does not have a >> 64-bit core and processing 64-bit elements will be as fast as >> processing 32-bit elements. > Michael Dillon wrote: > This may be true in the domain of trendy laptop and > desktop computers, but I cannot believe that it will > be true overall. We still have millions of 8-bit CPUs > being built into devices every year and there is nothing > on the horizon that indicates manufacturers will stop Totally irrelevant. We are talking about routers that have a full view of the global routing table here. Cisco 7600 or 12000 or CRS-1. Juniper M or T series. These are not built on 8-bit processors. Are you planning on running an ISP core on Linksys gear? Gee, even my PDA has a 16-bit processor. This argument about optimization does not hold water. Besides, and as pointed out by several other contributors, policies can be changed rather quickly. Have a single vendor come forward and say that they would like sites to get a /32 instead of a /48 because it makes their life easier and we'll consider it. A site is a /48, has always been, and this what a site will get. I will add that that allocation policies are indeed RIR matter, addressing architecture is an IETF matter and if you want sites to be redefined you need to bring the matter before the IETF not here. > Owen DeLong wrote: > Trying to drive policy into insanely large allocations for > multihomed organizations that may be no larger than a dorm room Gee, do you know any that would do this? People who would have a public ASN for their home or their dorm? What a waste. Michel. From iggy at merit.edu Sun Apr 17 11:52:09 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Sun, 17 Apr 2005 11:52:09 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <20050415192306.GB95722@ussenterprise.ufp.org> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> Message-ID: I'm really not comfortable aproving this policy without knowing many of these deffinitions and procedures. I may be willing to support most of this as a sort of trial policy that would not become 'offical' without some future vote at anohter ARIN policy meeting. By offical, I guess what I'm saying is I don't like the idea of ARIN reclaiming any address space before we all know exactly what the deffinitions and procedures are. The deffintions and procedures should also not be allowed to change without future aproval at a policy meeting. After ariving in Orlando and getting my registration packets, I read Raymond Plzak's 'observations' related to ARIN directory Services & Data... I noticed some interesting stuff that made me think more about what drives some of my underlying feelings of being uncomfortable with the proposed policy (2005-2). From Section 4.1 of that document... What should be the consquence of failing to maintain accurate data? What should be the conequence of inserting fraudulent data? Let me give you my own personal opion... Relating to this policy discussion... I feel the only valid reason to 'reclaim' a ARIN resource should be FRAUD. Failing to maintain accurate data, should at worst result in the removal or flaging of the data, not in reclimation of resources. Now, if you could prove that the inaccurate data is actualy fraudulent data, then reclimation would be reasonable. Now you may think that this is somewhat like spliting hairs as to when in-accurate data becomes fraudulent data, however I see this a a critical item, and quite frankly should be left to the the actual legal system and not ARIN policy or staff. Let me get back to a specific part of this policy proposal that I don't like... "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." I belive that there are I suggest to you that there can be valid re-assignments of ARIN resources, that may for a varitey of reasons become non-responsive for preiods of a month or longer, and should not constitute anything close to being grounds for reclaimation or maybe not even be grounds for 'suspension'(depending on how that is defined). Consider something such as a seasonal business, or a very small busines where possibly the entire staff is gone for a month or more. (possibly a small family based business, etc...) Well, you say ARIN staff can use there 'discretion' to determin that this is something that doesn't constitute a offense. I say that there shouldn't be room for ARIN staffs descretion... The only reason for reclaiming resources based on 'inaccurate' or 'non responsive' contacts, is FRAUD, which is legaly defined. Glenn Wiltse On Fri, 15 Apr 2005, Leo Bicknell wrote: > In a message written on Fri, Apr 15, 2005 at 10:34:02AM -0400, Glenn Wiltse wrote: > > I've got ALOT of concerns about this proposal. More then I do with > > 2005-3. Ed Lewis rasied several good points that I too am concerned about > > relating to this proposal. Many of these terms such as SUSPEND, reclaim, > > offenders, or even non-responsive, don't seem to be defined very well if > > at all. The problems I have with this proposal are too numerous to go into > > in every detail right now. > > They are not defined in the /policy/, which is not to say they are > not defined. For instance with regards to "non-responsive", I > quote: > > ] The ARIN staff shall publish the time thresholds and procedural > ] details to implement this policy on the ARIN web site. > > So before ARIN staff can call someone non-responsive they must > publish the procedure they will use to contact people, and the > amount of time to repspond before considered non-responsive. > > The reason the methods and timeframes are not spelled out in the > policy is rooted in ARIN's own history of such things. They never > go as planned. Perhaps they start with e-mail, but find as they > do it phone always works better. Perhaps they start out with 3 > months, but find out that makes the workload too hard so it's better > to go to 6 months. At the end of the day, what's important is that > these are implementation details, not policy details. We don't > want policies that say "ARIN Staff will call the listed phonenumber > on the thrid tuesday of the month at 2:30PM to see if you answer." > They don't work. > > So yes, non-responsive is not defined in this policy, but it must > be defined and published by staff prior to the implementation of > the policy, and may be modified from time to time by the staff as > approproate without having to go through a 2+year policy cycle. > Sticking the staff, and ARIN members with bad methods or timeframes > for 2+ years because that's how long it takes to change a policy > is not a good course of action. > > > Let me just ask about 'reclaim' a resource... Does that mean if a > > ISP should assign a /24 to a customer, and that customer should commit > > these 'offenses', do you then reclaim a whole /14 or larger resorce that > > the /24 is part of? > > The policy allows for that possibility, however, in practice I don't see > how it could ever occur. > > To get to a reclaim state, you have to go through the following steps: > > 1) Someone gets a resource. > > 2) ARIN attempts to verify the contact information. > > 3) Verification fails. > > 4) ARIN notifies the upstream. (Note, there is a branch here in the > policy depending on if it is a verification problem with an ARIN > allocation, or with suballocation information. I'm considering the > suballocation case as you asked about the "/24 to a customer" version). > > 5) The upstream does not correct the problem in a reasonable amount of > time. > > 6) The resource becomes suspended. > > 7) ARIN recontacts the upstream, asking them again to fix the problem. > > 8) The upstream does not correct the problem in a reasonable amount of > time again. > > 9) The resource (eg, the /14) can be reclaimed. > > Now, for #5 and #8, the upstream has several choices to correct the > problem. First, they can update the name/address/phone/e-mail that > is wrong. Since this is a customer I see no reason why the ISP > wouldn't have that information, after all they are probably billing > the person. Second, if that's too hard for some reason under this > policy they can simply remove the record. No record is required > (publically viewable), so no record is ok. No record, no bad info, > problem corrected. > > Given both of these corrections are boardline trivial, and the > upstream gets two shots with a "reasonable amount of time" (which > I would think would be some number of weeks) to make the fixes, I > don't really see how it could ever happen. However, an interesting > case is the company that goes belly up completely, closing the doors > never to be heard from again. In that case it might get there, and > ARIN would be right to reclaim the resource. > > > Aside from these concerns... If ARIN staff don't have time to track down > > 'lame delegation' offenders... how are they ever going to tackle this job > > being proposed here? This is potentialy a HUGE amount of work for ARIN and > > for ISPs with large amounts of re-assignment information. I think this is > > way too agressive of a aproach. > > Well, first, we don't have the ARIN staff impact analysis, something I > am eager to see myself. They do have some experience in this area > (mainly from the lame delegation work) so their estimates will be very > interesting. > > As for how "agressive" it is, I'm not sure how you can make that > statement. There's no timeline in this document, specifically so > if does take a lot of man hours they can set a verification time > of "once a year" or similarly long time to reduce the workload. > There's no requirement this happen once a week, or even anything > approching "frequently". > > In terms of wasting staff time, I'm more concerned right now that > we're spending man hours on both ARIN's side and the ISP's side to > enter data that is worthless. That's the real waste. It's not > hard to find thousands of records which are no good. While getting > over the hump and removing the old data is going to be a huge amount > of work, waiting will only make that task larger later as we're > still adding to the mess. Once the data is cleaned up, the overall > work load for ARIN staff and for customers should be significantly > reduced. > > -- > 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 > From owen at delong.com Sun Apr 17 17:07:19 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Apr 2005 14:07:19 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> Message-ID: <2147483647.1113746839@imac-en0.delong.sj.ca.us> > Let me give you my own personal opion... Relating to this policy > discussion... I feel the only valid reason to 'reclaim' a ARIN resource > should be FRAUD. Failing to maintain accurate data, should at worst result > in the removal or flaging of the data, not in reclimation of resources. > Now, if you could prove that the inaccurate data is actually fraudulent > data, then reclimation would be reasonable. Now you may think that this is > somewhat like spliting hairs as to when in-accurate data becomes > fraudulent data, however I see this a a critical item, and quite frankly > should be left to the the actual legal system and not ARIN policy or > staff. > If you provide inaccurate data, and, then, are unreachable, the data is essentially fraudulent. If you provide inaccurate data, and, then refuse to correct it even though you are reachable, the data is definitely fraudulent, so, yes, I think you are splitting hairs from a practical ARIN perspective. ARIN may already reclaim resources for non-payment of renewal fees. As such, if ARIN cannot contact you (case 1 above), you will not receive your bill and it is unlikely the renewal will be paid. In the second case, the data qualifies as fraudulent. If you pay your fees, but, do not provide current accurate contact data when you do so, I believe that qualifies as intent to defraud. > Let me get back to a specific part of this policy proposal that I don't > like... > > "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." I belive that there are > > I suggest to you that there can be valid re-assignments of ARIN > resources, that may for a varitey of reasons become non-responsive for > preiods of a month or longer, and should not constitute anything close to > being grounds for reclaimation or maybe not even be grounds for > 'suspension'(depending on how that is defined). Consider something such > as a seasonal business, or a very small busines where possibly the entire > staff is gone for a month or more. (possibly a small family based > business, etc...) Well, you say ARIN staff can use there 'discretion' to > determin that this is something that doesn't constitute a offense. I say > that there shouldn't be room for ARIN staffs descretion... The only reason > for reclaiming resources based on 'inaccurate' or 'non responsive' > contacts, is FRAUD, which is legaly defined. > And it doesn't... It requires 4 times per month for three months. There's no legitimate reason for a valid POC for a network resource to be unreachable for 3 months solid. A Seasonal business should have a responsive backup POC from their upstream or such. Otherwise, the rest of the world is expected to live with their resources being abused while they aren't looking? I think that is bad for the world. 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 jwkckid1 at ix.netcom.com Mon Apr 18 00:15:57 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Sun, 17 Apr 2005 21:15:57 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> Message-ID: <4263347A.45F5D1B2@ix.netcom.com> Glenn and all, I don't like the idea that the ARIN staff has significant leeway with regard to discretion. Discretion is a very nebulous thing and can be easily inappropriately or improperly applied for any number of reasons. Hence a hard and fast policy for reclaiming resources is unfortunately necessary. Glenn Wiltse wrote: > I'm really not comfortable aproving this policy without knowing many > of these deffinitions and procedures. I may be willing to support most > of this as a sort of trial policy that would not become 'offical' without > some future vote at anohter ARIN policy meeting. By offical, I guess what > I'm saying is I don't like the idea of ARIN reclaiming any address space > before we all know exactly what the deffinitions and procedures are. The > deffintions and procedures should also not be allowed to change without > future aproval at a policy meeting. > > After ariving in Orlando and getting my registration packets, I read > Raymond Plzak's 'observations' related to ARIN directory Services & > Data... I noticed some interesting stuff that made me think more > about what drives some of my underlying feelings of being uncomfortable > with the proposed policy (2005-2). From Section 4.1 of that document... > > What should be the consquence of failing to maintain accurate data? > What should be the conequence of inserting fraudulent data? > > Let me give you my own personal opion... Relating to this policy > discussion... I feel the only valid reason to 'reclaim' a ARIN resource > should be FRAUD. Failing to maintain accurate data, should at worst result > in the removal or flaging of the data, not in reclimation of resources. > Now, if you could prove that the inaccurate data is actualy fraudulent > data, then reclimation would be reasonable. Now you may think that this is > somewhat like spliting hairs as to when in-accurate data becomes > fraudulent data, however I see this a a critical item, and quite frankly > should be left to the the actual legal system and not ARIN policy or > staff. > > Let me get back to a specific part of this policy proposal that I don't > like... > > "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." I belive that there are > > I suggest to you that there can be valid re-assignments of ARIN > resources, that may for a varitey of reasons become non-responsive for > preiods of a month or longer, and should not constitute anything close to > being grounds for reclaimation or maybe not even be grounds for > 'suspension'(depending on how that is defined). Consider something such > as a seasonal business, or a very small busines where possibly the entire > staff is gone for a month or more. (possibly a small family based > business, etc...) Well, you say ARIN staff can use there 'discretion' to > determin that this is something that doesn't constitute a offense. I say > that there shouldn't be room for ARIN staffs descretion... The only reason > for reclaiming resources based on 'inaccurate' or 'non responsive' > contacts, is FRAUD, which is legaly defined. > > Glenn Wiltse > > On Fri, 15 Apr 2005, Leo Bicknell wrote: > > > In a message written on Fri, Apr 15, 2005 at 10:34:02AM -0400, Glenn Wiltse wrote: > > > I've got ALOT of concerns about this proposal. More then I do with > > > 2005-3. Ed Lewis rasied several good points that I too am concerned about > > > relating to this proposal. Many of these terms such as SUSPEND, reclaim, > > > offenders, or even non-responsive, don't seem to be defined very well if > > > at all. The problems I have with this proposal are too numerous to go into > > > in every detail right now. > > > > They are not defined in the /policy/, which is not to say they are > > not defined. For instance with regards to "non-responsive", I > > quote: > > > > ] The ARIN staff shall publish the time thresholds and procedural > > ] details to implement this policy on the ARIN web site. > > > > So before ARIN staff can call someone non-responsive they must > > publish the procedure they will use to contact people, and the > > amount of time to repspond before considered non-responsive. > > > > The reason the methods and timeframes are not spelled out in the > > policy is rooted in ARIN's own history of such things. They never > > go as planned. Perhaps they start with e-mail, but find as they > > do it phone always works better. Perhaps they start out with 3 > > months, but find out that makes the workload too hard so it's better > > to go to 6 months. At the end of the day, what's important is that > > these are implementation details, not policy details. We don't > > want policies that say "ARIN Staff will call the listed phonenumber > > on the thrid tuesday of the month at 2:30PM to see if you answer." > > They don't work. > > > > So yes, non-responsive is not defined in this policy, but it must > > be defined and published by staff prior to the implementation of > > the policy, and may be modified from time to time by the staff as > > approproate without having to go through a 2+year policy cycle. > > Sticking the staff, and ARIN members with bad methods or timeframes > > for 2+ years because that's how long it takes to change a policy > > is not a good course of action. > > > > > Let me just ask about 'reclaim' a resource... Does that mean if a > > > ISP should assign a /24 to a customer, and that customer should commit > > > these 'offenses', do you then reclaim a whole /14 or larger resorce that > > > the /24 is part of? > > > > The policy allows for that possibility, however, in practice I don't see > > how it could ever occur. > > > > To get to a reclaim state, you have to go through the following steps: > > > > 1) Someone gets a resource. > > > > 2) ARIN attempts to verify the contact information. > > > > 3) Verification fails. > > > > 4) ARIN notifies the upstream. (Note, there is a branch here in the > > policy depending on if it is a verification problem with an ARIN > > allocation, or with suballocation information. I'm considering the > > suballocation case as you asked about the "/24 to a customer" version). > > > > 5) The upstream does not correct the problem in a reasonable amount of > > time. > > > > 6) The resource becomes suspended. > > > > 7) ARIN recontacts the upstream, asking them again to fix the problem. > > > > 8) The upstream does not correct the problem in a reasonable amount of > > time again. > > > > 9) The resource (eg, the /14) can be reclaimed. > > > > Now, for #5 and #8, the upstream has several choices to correct the > > problem. First, they can update the name/address/phone/e-mail that > > is wrong. Since this is a customer I see no reason why the ISP > > wouldn't have that information, after all they are probably billing > > the person. Second, if that's too hard for some reason under this > > policy they can simply remove the record. No record is required > > (publically viewable), so no record is ok. No record, no bad info, > > problem corrected. > > > > Given both of these corrections are boardline trivial, and the > > upstream gets two shots with a "reasonable amount of time" (which > > I would think would be some number of weeks) to make the fixes, I > > don't really see how it could ever happen. However, an interesting > > case is the company that goes belly up completely, closing the doors > > never to be heard from again. In that case it might get there, and > > ARIN would be right to reclaim the resource. > > > > > Aside from these concerns... If ARIN staff don't have time to track down > > > 'lame delegation' offenders... how are they ever going to tackle this job > > > being proposed here? This is potentialy a HUGE amount of work for ARIN and > > > for ISPs with large amounts of re-assignment information. I think this is > > > way too agressive of a aproach. > > > > Well, first, we don't have the ARIN staff impact analysis, something I > > am eager to see myself. They do have some experience in this area > > (mainly from the lame delegation work) so their estimates will be very > > interesting. > > > > As for how "agressive" it is, I'm not sure how you can make that > > statement. There's no timeline in this document, specifically so > > if does take a lot of man hours they can set a verification time > > of "once a year" or similarly long time to reduce the workload. > > There's no requirement this happen once a week, or even anything > > approching "frequently". > > > > In terms of wasting staff time, I'm more concerned right now that > > we're spending man hours on both ARIN's side and the ISP's side to > > enter data that is worthless. That's the real waste. It's not > > hard to find thousands of records which are no good. While getting > > over the hump and removing the old data is going to be a huge amount > > of work, waiting will only make that task larger later as we're > > still adding to the mess. Once the data is cleaned up, the overall > > work load for ARIN staff and for customers should be significantly > > reduced. > > > > -- > > 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 > > 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 william at elan.net Sun Apr 17 22:44:08 2005 From: william at elan.net (william(at)elan.net) Date: Sun, 17 Apr 2005 19:44:08 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <4263347A.45F5D1B2@ix.netcom.com> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> Message-ID: On Sun, 17 Apr 2005, Jeff Williams wrote: > Glenn and all, > > I don't like the idea that the ARIN staff has significant leeway with > regard to discretion. Discretion is a very nebulous thing and can be > easily inappropriately or improperly applied for any number of > reasons. Hence a hard and fast policy for reclaiming resources > is unfortunately necessary. There are a lot of circumstances that can be involved that its difficult to predict by policy text right now. It is probably better that we give ARIN staff some discretion but require them to report on how its been used and if we see that there have been cases that ARIN staff seems to not be applyng "their discretion" in the right way then policy can always be toughened (but already we'd have certain amount of experience and be able to write more detailed policy). This is better then somebody loosing the block because we were too tough and did not account for their special circumstance. >> After ariving in Orlando and getting my registration packets, I read >> Raymond Plzak's 'observations' related to ARIN directory Services & >> Data... I noticed some interesting stuff that made me think more >> about what drives some of my underlying feelings of being uncomfortable >> with the proposed policy (2005-2). From Section 4.1 of that document... And for those not attending were can we read those 'observations'? ARIN staff should really work harder on giving equality to availability of documents to all the ARIN policy process participants (no matter if one is attending meeting or not). As it is is, its 2nd time (in last 4 years) that I'm not able to attend the meeting and yet again I see policy-related documents mentioned that only meeting attendees have access to ... -- William Leibzon Elan Networks william at elan.net From owen at delong.com Mon Apr 18 00:28:43 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Apr 2005 21:28:43 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <4263347A.45F5D1B2@ix.netcom.com> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> Message-ID: <2147483647.1113773323@[172.17.1.152]> A hard and fast policy is only preferable to discretion if the hard and fast policy limits the power of the staff to reclaim resources. In this case, the leeway or discretion being given is the option of NOT reclaiming resources in circumstances which would otherwise fit the policy if the staff believes this to be wrong. I believe that form of discretion is not only desirable, but, necessary at least until we have had some experience and opportunity to fine tune such a policy. Between you and Glenn, you have now convinced me to fully support 2005-2 as it is currently written. Owen --On Sunday, April 17, 2005 21:15 -0700 Jeff Williams wrote: > Glenn and all, > > I don't like the idea that the ARIN staff has significant leeway with > regard to discretion. Discretion is a very nebulous thing and can be > easily inappropriately or improperly applied for any number of > reasons. Hence a hard and fast policy for reclaiming resources > is unfortunately necessary. > > Glenn Wiltse wrote: > >> I'm really not comfortable aproving this policy without knowing many >> of these deffinitions and procedures. I may be willing to support most >> of this as a sort of trial policy that would not become 'offical' without >> some future vote at anohter ARIN policy meeting. By offical, I guess what >> I'm saying is I don't like the idea of ARIN reclaiming any address space >> before we all know exactly what the deffinitions and procedures are. The >> deffintions and procedures should also not be allowed to change without >> future aproval at a policy meeting. >> >> After ariving in Orlando and getting my registration packets, I read >> Raymond Plzak's 'observations' related to ARIN directory Services & >> Data... I noticed some interesting stuff that made me think more >> about what drives some of my underlying feelings of being uncomfortable >> with the proposed policy (2005-2). From Section 4.1 of that document... >> >> What should be the consquence of failing to maintain accurate data? >> What should be the conequence of inserting fraudulent data? >> >> Let me give you my own personal opion... Relating to this policy >> discussion... I feel the only valid reason to 'reclaim' a ARIN resource >> should be FRAUD. Failing to maintain accurate data, should at worst >> result in the removal or flaging of the data, not in reclimation of >> resources. Now, if you could prove that the inaccurate data is actually >> fraudulent data, then reclimation would be reasonable. Now you may think >> that this is somewhat like spliting hairs as to when in-accurate data >> becomes fraudulent data, however I see this a a critical item, and quite >> frankly should be left to the the actual legal system and not ARIN >> policy or staff. >> >> Let me get back to a specific part of this policy proposal that I don't >> like... >> >> "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." I belive that there are >> >> I suggest to you that there can be valid re-assignments of ARIN >> resources, that may for a varitey of reasons become non-responsive for >> preiods of a month or longer, and should not constitute anything close to >> being grounds for reclaimation or maybe not even be grounds for >> 'suspension'(depending on how that is defined). Consider something such >> as a seasonal business, or a very small busines where possibly the entire >> staff is gone for a month or more. (possibly a small family based >> business, etc...) Well, you say ARIN staff can use there 'discretion' to >> determin that this is something that doesn't constitute a offense. I say >> that there shouldn't be room for ARIN staffs descretion... The only >> reason for reclaiming resources based on 'inaccurate' or 'non responsive' >> contacts, is FRAUD, which is legaly defined. >> >> Glenn Wiltse >> >> On Fri, 15 Apr 2005, Leo Bicknell wrote: >> >> > In a message written on Fri, Apr 15, 2005 at 10:34:02AM -0400, Glenn >> > Wiltse wrote: >> > > I've gotA LOTT of concerns about this proposal. More then I do with >> > > 2005-3. Ed Lewis rasied several good points that I too am concerned >> > > about relating to this proposal. Many of these terms such as >> > > SUSPEND, reclaim, offenders, or even non-responsive, don't seem to >> > > be defined very well if at all. The problems I have with this >> > > proposal are too numerous to go into in every detail right now. >> > >> > They are not defined in the /policy/, which is not to say they are >> > not defined. For instance with regards to "non-responsive", I >> > quote: >> > >> > ] The ARIN staff shall publish the time thresholds and >> > procedural ] details to implement this policy on the ARIN web >> > site. >> > >> > So before ARIN staff can call someone non-responsive they must >> > publish the procedure they will use to contact people, and the >> > amount of time to repspond before considered non-responsive. >> > >> > The reason the methods and timeframes are not spelled out in the >> > policy is rooted in ARIN's own history of such things. They never >> > go as planned. Perhaps they start with e-mail, but find as they >> > do it phone always works better. Perhaps they start out with 3 >> > months, but find out that makes the workload too hard so it's better >> > to go to 6 months. At the end of the day, what's important is that >> > these are implementation details, not policy details. We don't >> > want policies that say "ARIN Staff will call the listed phonenumber >> > on the thriTuesdayay of the month at 2:30PM to see if you answer." >> > They don't work. >> > >> > So yes, non-responsive is not defined in this policy, but it must >> > be defined and published by staff prior to the implementation of >> > the policy, and may be modified from time to time by the staff as >> > approproate without having to go through a 2+year policy cycle. >> > Sticking the staff, and ARIN members with bad methods or timeframes >> > for 2+ years because that's how long it takes to change a policy >> > is not a good course of action. >> > >> > > Let me just ask about 'reclaim' a resource... Does that mean if a >> > > ISP should assign a /24 to a customer, and that customer should >> > > commit these 'offenses', do you then reclaim a whole /14 or larger >> > > resorce that the /24 is part of? >> > >> > The policy allows for that possibility, however, in practice I don't >> > see how it could ever occur. >> > >> > To get to a reclaim state, you have to go through the following steps: >> > >> > 1) Someone gets a resource. >> > >> > 2) ARIN attempts to verify the contact information. >> > >> > 3) Verification fails. >> > >> > 4) ARIN notifies the upstream. (Note, there is a branch here in the >> > policy depending on if it is a verification problem with an ARIN >> > allocation, or with suballocation information. I'm considering the >> > suballocation case as you asked about the "/24 to a customer" >> > version). >> > >> > 5) The upstream does not correct the problem in a reasonable amount of >> > time. >> > >> > 6) The resource becomes suspended. >> > >> > 7) ARIN recontacts the upstream, asking them again to fix the problem. >> > >> > 8) The upstream does not correct the problem in a reasonable amount of >> > time again. >> > >> > 9) The resource (eg, the /14) can be reclaimed. >> > >> > Now, for #5 and #8, the upstream has several choices to correct the >> > problem. First, they can update the name/address/phone/e-mail that >> > is wrong. Since this is a customer I see no reason why the ISP >> > wouldn't have that information, after all they are probably billing >> > the person. Second, if that's too hard for some reason under this >> > policy they can simply remove the record. No record is required >> >publiclyly viewable), so no record is ok. No record, no bad info, >> > problem corrected. >> > >> > Given both of these corrections are boardline trivial, and the >> > upstream gets two shots with a "reasonable amount of time" (which >> > I would think would be some number of weeks) to make the fixes, I >> > don't really see how it could ever happen. However, an interesting >> > case is the company that goes belly up completely, closing the doors >> > never to be heard from again. In that case it might get there, and >> > ARIN would be right to reclaim the resource. >> > >> > > Aside from these concerns... If ARIN staff don't have time to track >> > > down 'lame delegation' offenders... how are they ever going to >> > > tackle this job being proposed here? This is potentially a HUGE >> > > amount of work for ARIN and for ISPs with large amounts of >> > > re-assignment information. I think this is way tooaggressivee of a >> > > aproach. >> > >> > Well, first, we don't have the ARIN staff impact analysis, something I >> > am eager to see myself. They do have some experience in this area >> > (mainly from the lame delegation work) so their estimates will be very >> > interesting. >> > >> > As for howaggressiveve" it is, I'm not sure how you can make that >> > statement. There's no timeline in this document, specifically so >> > if does take a lot of man hours they can set a verification time >> > of "once a year" or similarly long time to reduce the workload. >> > There's no requirement this happen once a week, or even anything >> > approching "frequently". >> > >> > In terms of wasting staff time, I'm more concerned right now that >> > we're spending man hours on both ARIN's side and the ISP's side to >> > enter data that is worthless. That's the real waste. It's not >> > hard to find thousands of records which are no good. While getting >> > over the hump and removing the old data is going to be a huge amount >> > of work, waiting will only make that task larger later as we're >> > still adding to the mess. Once the data is cleaned up, the overall >> > work load for ARIN staff and for customers should be significantly >> > reduced. >> > >> > -- >> > 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 >> > > > 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 > > -- 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 jwkckid1 at ix.netcom.com Mon Apr 18 02:37:04 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Sun, 17 Apr 2005 23:37:04 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <2147483647.1113773323@[172.17.1.152]> Message-ID: <4263558C.D7349246@ix.netcom.com> Owen and all, It is often true that hard and fast policies once established can be wrong or become wrong. Hence I can understand your propensity for allowing ARIN staff to exercise some discretionary authority. However, that said, I am sorry your thought processes are so indelibly limited to anything I or Glenn has said. Such seems a bit myopic in nature. So I hope you will try to be more open minded or broad minded. The many obvious reasons why having any staff of any organization to have discretionary authority over any limited resource are usually considered obvious. Hence in part my previous remarks. As we all should have by now learned, such discretion in the past has lead to a number of already discussed and debated problems with allocation and use of Ipv4 address space. I don't believe that these lessons need to be learned again. I hope no one else does either. So Owen, I hope you will reconsider your reason for your decision based on a more broad thoughtful way. Of course you may still arrive at the same decision. >:) Owen DeLong wrote: > A hard and fast policy is only preferable to discretion if the hard and > fast policy limits the power of the staff to reclaim resources. In this > case, the leeway or discretion being given is the option of NOT reclaiming > resources in circumstances which would otherwise fit the policy if the > staff believes this to be wrong. I believe that form of discretion is > not only desirable, but, necessary at least until we have had some > experience and opportunity to fine tune such a policy. > > Between you and Glenn, you have now convinced me to fully support 2005-2 as > it is currently written. > > Owen > > --On Sunday, April 17, 2005 21:15 -0700 Jeff Williams > wrote: > > > Glenn and all, > > > > I don't like the idea that the ARIN staff has significant leeway with > > regard to discretion. Discretion is a very nebulous thing and can be > > easily inappropriately or improperly applied for any number of > > reasons. Hence a hard and fast policy for reclaiming resources > > is unfortunately necessary. > > > > Glenn Wiltse wrote: > > > >> I'm really not comfortable aproving this policy without knowing many > >> of these deffinitions and procedures. I may be willing to support most > >> of this as a sort of trial policy that would not become 'offical' without > >> some future vote at anohter ARIN policy meeting. By offical, I guess what > >> I'm saying is I don't like the idea of ARIN reclaiming any address space > >> before we all know exactly what the deffinitions and procedures are. The > >> deffintions and procedures should also not be allowed to change without > >> future aproval at a policy meeting. > >> > >> After ariving in Orlando and getting my registration packets, I read > >> Raymond Plzak's 'observations' related to ARIN directory Services & > >> Data... I noticed some interesting stuff that made me think more > >> about what drives some of my underlying feelings of being uncomfortable > >> with the proposed policy (2005-2). From Section 4.1 of that document... > >> > >> What should be the consquence of failing to maintain accurate data? > >> What should be the conequence of inserting fraudulent data? > >> > >> Let me give you my own personal opion... Relating to this policy > >> discussion... I feel the only valid reason to 'reclaim' a ARIN resource > >> should be FRAUD. Failing to maintain accurate data, should at worst > >> result in the removal or flaging of the data, not in reclimation of > >> resources. Now, if you could prove that the inaccurate data is actually > >> fraudulent data, then reclimation would be reasonable. Now you may think > >> that this is somewhat like spliting hairs as to when in-accurate data > >> becomes fraudulent data, however I see this a a critical item, and quite > >> frankly should be left to the the actual legal system and not ARIN > >> policy or staff. > >> > >> Let me get back to a specific part of this policy proposal that I don't > >> like... > >> > >> "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." I belive that there are > >> > >> I suggest to you that there can be valid re-assignments of ARIN > >> resources, that may for a varitey of reasons become non-responsive for > >> preiods of a month or longer, and should not constitute anything close to > >> being grounds for reclaimation or maybe not even be grounds for > >> 'suspension'(depending on how that is defined). Consider something such > >> as a seasonal business, or a very small busines where possibly the entire > >> staff is gone for a month or more. (possibly a small family based > >> business, etc...) Well, you say ARIN staff can use there 'discretion' to > >> determin that this is something that doesn't constitute a offense. I say > >> that there shouldn't be room for ARIN staffs descretion... The only > >> reason for reclaiming resources based on 'inaccurate' or 'non responsive' > >> contacts, is FRAUD, which is legaly defined. > >> > >> Glenn Wiltse > >> > >> On Fri, 15 Apr 2005, Leo Bicknell wrote: > >> > >> > In a message written on Fri, Apr 15, 2005 at 10:34:02AM -0400, Glenn > >> > Wiltse wrote: > >> > > I've gotA LOTT of concerns about this proposal. More then I do > with > >> > > 2005-3. Ed Lewis rasied several good points that I too am concerned > >> > > about relating to this proposal. Many of these terms such as > >> > > SUSPEND, reclaim, offenders, or even non-responsive, don't seem to > >> > > be defined very well if at all. The problems I have with this > >> > > proposal are too numerous to go into in every detail right now. > >> > > >> > They are not defined in the /policy/, which is not to say they are > >> > not defined. For instance with regards to "non-responsive", I > >> > quote: > >> > > >> > ] The ARIN staff shall publish the time thresholds and > >> > procedural ] details to implement this policy on the ARIN web > >> > site. > >> > > >> > So before ARIN staff can call someone non-responsive they must > >> > publish the procedure they will use to contact people, and the > >> > amount of time to repspond before considered non-responsive. > >> > > >> > The reason the methods and timeframes are not spelled out in the > >> > policy is rooted in ARIN's own history of such things. They never > >> > go as planned. Perhaps they start with e-mail, but find as they > >> > do it phone always works better. Perhaps they start out with 3 > >> > months, but find out that makes the workload too hard so it's better > >> > to go to 6 months. At the end of the day, what's important is that > >> > these are implementation details, not policy details. We don't > >> > want policies that say "ARIN Staff will call the listed phonenumber > >> > on the thriTuesdayay of the month at 2:30PM to see if you answer." > >> > They don't work. > >> > > >> > So yes, non-responsive is not defined in this policy, but it must > >> > be defined and published by staff prior to the implementation of > >> > the policy, and may be modified from time to time by the staff as > >> > approproate without having to go through a 2+year policy cycle. > >> > Sticking the staff, and ARIN members with bad methods or timeframes > >> > for 2+ years because that's how long it takes to change a policy > >> > is not a good course of action. > >> > > >> > > Let me just ask about 'reclaim' a resource... Does that mean if a > >> > > ISP should assign a /24 to a customer, and that customer should > >> > > commit these 'offenses', do you then reclaim a whole /14 or larger > >> > > resorce that the /24 is part of? > >> > > >> > The policy allows for that possibility, however, in practice I don't > >> > see how it could ever occur. > >> > > >> > To get to a reclaim state, you have to go through the following steps: > >> > > >> > 1) Someone gets a resource. > >> > > >> > 2) ARIN attempts to verify the contact information. > >> > > >> > 3) Verification fails. > >> > > >> > 4) ARIN notifies the upstream. (Note, there is a branch here in the > >> > policy depending on if it is a verification problem with an ARIN > >> > allocation, or with suballocation information. I'm considering the > >> > suballocation case as you asked about the "/24 to a customer" > >> > version). > >> > > >> > 5) The upstream does not correct the problem in a reasonable amount of > >> > time. > >> > > >> > 6) The resource becomes suspended. > >> > > >> > 7) ARIN recontacts the upstream, asking them again to fix the problem. > >> > > >> > 8) The upstream does not correct the problem in a reasonable amount of > >> > time again. > >> > > >> > 9) The resource (eg, the /14) can be reclaimed. > >> > > >> > Now, for #5 and #8, the upstream has several choices to correct the > >> > problem. First, they can update the name/address/phone/e-mail that > >> > is wrong. Since this is a customer I see no reason why the ISP > >> > wouldn't have that information, after all they are probably billing > >> > the person. Second, if that's too hard for some reason under this > >> > policy they can simply remove the record. No record is required > >> >publiclyly viewable), so no record is ok. No record, no bad info, > >> > problem corrected. > >> > > >> > Given both of these corrections are boardline trivial, and the > >> > upstream gets two shots with a "reasonable amount of time" (which > >> > I would think would be some number of weeks) to make the fixes, I > >> > don't really see how it could ever happen. However, an interesting > >> > case is the company that goes belly up completely, closing the doors > >> > never to be heard from again. In that case it might get there, and > >> > ARIN would be right to reclaim the resource. > >> > > >> > > Aside from these concerns... If ARIN staff don't have time to track > >> > > down 'lame delegation' offenders... how are they ever going to > >> > > tackle this job being proposed here? This is potentially a HUGE > >> > > amount of work for ARIN and for ISPs with large amounts of > >> > > re-assignment information. I think this is way tooaggressivee of a > >> > > aproach. > >> > > >> > Well, first, we don't have the ARIN staff impact analysis, something I > >> > am eager to see myself. They do have some experience in this area > >> > (mainly from the lame delegation work) so their estimates will be very > >> > interesting. > >> > > >> > As for howaggressiveve" it is, I'm not sure how you can make that > >> > statement. There's no timeline in this document, specifically so > >> > if does take a lot of man hours they can set a verification time > >> > of "once a year" or similarly long time to reduce the workload. > >> > There's no requirement this happen once a week, or even anything > >> > approching "frequently". > >> > > >> > In terms of wasting staff time, I'm more concerned right now that > >> > we're spending man hours on both ARIN's side and the ISP's side to > >> > enter data that is worthless. That's the real waste. It's not > >> > hard to find thousands of records which are no good. While getting > >> > over the hump and removing the old data is going to be a huge amount > >> > of work, waiting will only make that task larger later as we're > >> > still adding to the mess. Once the data is cleaned up, the overall > >> > work load for ARIN staff and for customers should be significantly > >> > reduced. > >> > > >> > -- > >> > 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 > >> > > > > > 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 > > > > > > -- > If this message was not signed with gpg key 0FE2AA3D, it's probably > a forgery. > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit 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 jwkckid1 at ix.netcom.com Mon Apr 18 02:46:37 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Sun, 17 Apr 2005 23:46:37 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> Message-ID: <426357CB.851CA2A7@ix.netcom.com> William and all, Thank you for your reasoned remarks. I can understand your attitude and concern here. Yet it seems more than obvious that discretion needs limits and hence a flexible policy seem appropriate that has hard and fast requirements regarding reporting, ect. How for instance will it be knowable if any ARIN staff member is using good and reasoned discretion? Or does one just assume such? I can for instance remember Jon Postal, god rest his kind soul, handing out IPv4 address blocks like they were so much candy at halloween. Is that good discretion? Or was it trick and treat? william(at)elan.net wrote: > On Sun, 17 Apr 2005, Jeff Williams wrote: > > > Glenn and all, > > > > I don't like the idea that the ARIN staff has significant leeway with > > regard to discretion. Discretion is a very nebulous thing and can be > > easily inappropriately or improperly applied for any number of > > reasons. Hence a hard and fast policy for reclaiming resources > > is unfortunately necessary. > > There are a lot of circumstances that can be involved that its difficult > to predict by policy text right now. It is probably better that we give > ARIN staff some discretion but require them to report on how its been > used and if we see that there have been cases that ARIN staff seems > to not be applyng "their discretion" in the right way then policy can > always be toughened (but already we'd have certain amount of experience > and be able to write more detailed policy). This is better then somebody > loosing the block because we were too tough and did not account for > their special circumstance. > > >> After ariving in Orlando and getting my registration packets, I read > >> Raymond Plzak's 'observations' related to ARIN directory Services & > >> Data... I noticed some interesting stuff that made me think more > >> about what drives some of my underlying feelings of being uncomfortable > >> with the proposed policy (2005-2). From Section 4.1 of that document... > > And for those not attending were can we read those 'observations'? > > ARIN staff should really work harder on giving equality to availability of > documents to all the ARIN policy process participants (no matter if one is > attending meeting or not). As it is is, its 2nd time (in last 4 years) > that I'm not able to attend the meeting and yet again I see policy-related > documents mentioned that only meeting attendees have access to ... > > -- > William Leibzon > Elan Networks > william at elan.net 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 owen at delong.com Mon Apr 18 02:29:21 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Apr 2005 23:29:21 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <4263558C.D7349246@ix.netcom.com> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <2147483647.1113773323@[172.17.1.152]> <4263558C.D7349246@ix.netcom.com> Message-ID: <2147483647.1113780561@[172.17.1.152]> --On Sunday, April 17, 2005 23:37 -0700 Jeff Williams wrote: > Owen and all, > > It is often true that hard and fast policies once established can > be wrong or become wrong. Hence I can understand your > propensity for allowing ARIN staff to exercise some discretionary > authority. However, that said, I am sorry your thought processes > are so indelibly limited to anything I or Glenn has said. Such seems > a bit myopic in nature. So I hope you will try to be more open > minded or broad minded. > I think you misunderstood my statement, sir. My decision is not inexorably linked to what you have said, I merely gave the two of you credit for convincing me. My mind remains very open to additional debate, but, the case the two of you have presented has, thus far, convinced me to shift my thoughts from skeptical consideration believing this policy was a flawed step in the correct direction to believing that the policy actually does address my objections fairly well and is a good starting point for dealing with the issues at hand. > The many obvious reasons why having any staff of any organization > to have discretionary authority over any limited resource are usually > considered obvious. Hence in part my previous remarks. As we You are correct, except... That statement applies when the discretion is the discretion to inflict additional harm. When the discretion is strictly limited to the discretion to prevent harm, said discretion is usually in the public interest, especially with new policies with minimal operational experience. The only reason this is a bad idea in law enforcement is that it encourages corruption. While, in the long run, it might be possible that people would "bribe corrupt ARIN officials to allow them to keep their inaccurate data in spite of refusal to correct it.", I don't think that is an issue in the immediate future. As such, by the time such an issue came up, I think we would have sufficient operational experience to deal with that and modify the policy accordingly. I also think that the oversight by the BOT and their emergency authority could be used to address any such situation that was detected or brought to their attention. As such, I think this is reasonably safe discretion to give to the staff under the current circumstances. They have much wider discretion WRT the issuance of ASNs and IP addresses than this policy would give them in preventing the revocation. The point here is that since this policy, as written, gives staff only the ability to prevent revocation and not the ability to cause revocation through their discretion, I believe this is very safe. You and Glenn have convinced me that is the case through your arguments. If someone presents compelling evidence this is not the case, I am open to that, but, the evidence you two have presented so far leads me to that conclusion, and, I am giving you appropriate credit for that. > all should have by now learned, such discretion in the past has lead > to a number of already discussed and debated problems with > allocation and use of Ipv4 address space. I don't believe that > these lessons need to be learned again. I hope no one else does > either. So Owen, I hope you will reconsider your reason for your > decision based on a more broad thoughtful way. Of course you > may still arrive at the same decision. >:) > Indeed, I believe that is what I did in the first place. I was already leaning towards support for this policy based on much broader consideration. Finally, I included the arguments put forth by you and Glenn as additional input, and, became convinced that the majority of the opposition to the policy was based on a misinterpretation of the harm this particular form of discretion could do. As a result, I concluded that support for this policy was the right thing to do. Owen -------------- 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 Mon Apr 18 02:46:37 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Apr 2005 23:46:37 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <426357CB.851CA2A7@ix.netcom.com> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <426357CB.851CA2A7@ix.netcom.com> Message-ID: <2147483647.1113781597@[172.17.1.152]> While I respect and understand your criticism of Jon Postel (that is the correct spelling of his name, btw), I think you must consider both his actions, and, the possible or likely actions of ARIN staff in appropriate context. When Jon was doing what you describe, it was at a time when virtually anyone could obtain an IP address and there was no expectation that they would become a scarce resource. Once we started seeing hints of scarcity and the need for CIDR due to routing table constraints on AGS boxes (remember those?), he stopped doing that. ARIN has never engaged in such behavior, though, technically, I suppose that certain members of the staff probably have the discretion to do so if they really chose to. However, in the current context of ARIN, there are layers of supervision within the staff and multiple peer reviews of such discretionary decisions, so, generally, corruption would require a conspiracy of corrupt individuals. Finally, any such discretionary action that was viewed as wrong would, in all likelihood be brought before this mailing list by the reporting party who saw the staff repeatedly refuse to reclaim the resources, as it would be appropriate at that point to comment that the existing policy was not working. Again, I just do not see a serious risk to the community from giving the current ARIN staff this discretion, nor, should the makeup of the staff change such that it is a concern, do I see this as even in the top 10 issues related to staff discretion. I also believe that by the time that happens, we will be in a much better position, with much better data to review what changes should be made to the policy to limit such discretion. As such, I think this policy is a good step in the right direction. Let's put it in place and get some data. When we have an idea of what would make it better, let's propose a new policy which amends it. That's the whole point of the ARIN IRPEP and this list. Owen --On Sunday, April 17, 2005 23:46 -0700 Jeff Williams wrote: > William and all, > > Thank you for your reasoned remarks. > > I can understand your attitude and concern here. Yet it seems > more than obvious that discretion needs limits and hence a > flexible policy seem appropriate that has hard and fast requirements > regarding reporting, ect. How for instance will it be knowable if > any ARIN staff member is using good and reasoned discretion? > Or does one just assume such? > > I can for instance remember Jon Postal, god rest his kind soul, > handing out IPv4 address blocks like they were so much candy > at halloween. Is that good discretion? Or was it trick and treat? > > william(at)elan.net wrote: > >> On Sun, 17 Apr 2005, Jeff Williams wrote: >> >> > Glenn and all, >> > >> > I don't like the idea that the ARIN staff has significant leeway with >> > regard to discretion. Discretion is a very nebulous thing and can be >> > easily inappropriately or improperly applied for any number of >> > reasons. Hence a hard and fast policy for reclaiming resources >> > is unfortunately necessary. >> >> There are a lot of circumstances that can be involved that its difficult >> to predict by policy text right now. It is probably better that we give >> ARIN staff some discretion but require them to report on how its been >> used and if we see that there have been cases that ARIN staff seems >> to not be applyng "their discretion" in the right way then policy can >> always be toughened (but already we'd have certain amount of experience >> and be able to write more detailed policy). This is better then somebody >> loosing the block because we were too tough and did not account for >> their special circumstance. >> >> >> After ariving in Orlando and getting my registration packets, I read >> >> Raymond Plzak's 'observations' related to ARIN directory Services & >> >> Data... I noticed some interesting stuff that made me think more >> >> about what drives some of my underlying feelings of being >> >> uncomfortable with the proposed policy (2005-2). From Section 4.1 of >> >> that document... >> >> And for those not attending were can we read those 'observations'? >> >> ARIN staff should really work harder on giving equality to availability >> of documents to all the ARIN policy process participants (no matter if >> one is attending meeting or not). As it is is, its 2nd time (in last 4 >> years) that I'm not able to attend the meeting and yet again I see >> policy-related documents mentioned that only meeting attendees have >> access to ... >> >> -- >> William Leibzon >> Elan Networks >> william at elan.net > > 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 > > -- 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 jwkckid1 at ix.netcom.com Mon Apr 18 05:33:30 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 18 Apr 2005 02:33:30 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <2147483647.1113773323@[172.17.1.152]> <4263558C.D7349246@ix.netcom.com> <2147483647.1113780561@[172.17.1.152]> Message-ID: <42637EE5.3B44F25B@ix.netcom.com> Qwen and all, > --On Sunday, April 17, 2005 23:37 -0700 Jeff Williams > wrote: > > > Owen and all, > > > > It is often true that hard and fast policies once established can > > be wrong or become wrong. Hence I can understand your > > propensity for allowing ARIN staff to exercise some discretionary > > authority. However, that said, I am sorry your thought processes > > are so indelibly limited to anything I or Glenn has said. Such seems > > a bit myopic in nature. So I hope you will try to be more open > > minded or broad minded. > > > I think you misunderstood my statement, sir. My decision is not inexorably > linked to what you have said, I merely gave the two of you credit for > convincing me. Understood of course. And I didn't not say or even intimate that I or Glenns' remarks or expressed thoughts here, were *inexorably* linked to convincing your decision.. Hence I believe you may have misunderstood me and/or Glenn... > My mind remains very open to additional debate, but, the > case the two of you have presented has, thus far, convinced me to > shift my thoughts from skeptical consideration believing this policy was > a flawed step in the correct direction to believing that the policy actually > does address my objections fairly well and is a good starting point for > dealing with the issues at hand. > > > The many obvious reasons why having any staff of any organization > > to have discretionary authority over any limited resource are usually > > considered obvious. Hence in part my previous remarks. As we > > You are correct, except... That statement applies when the discretion is > the discretion to inflict additional harm. a Yes and harm has already been inflicted on too many occasions for me to have kept count... > When the discretion is strictly > limited to the discretion to prevent harm, said discretion is usually in > the public interest, especially with new policies with minimal operational > experience. Agreed, except if harm has already occurred on multiple occasions, than the discretion exercised is either not good enough, improperly determined far to often, or has other motivations for such discretion to be exercised... > The only reason this is a bad idea in law enforcement is that > it encourages corruption. While, in the long run, it might be possible > that people would "bribe corrupt ARIN officials to allow them to keep > their inaccurate data in spite of refusal to correct it.", I don't think > that is an issue in the immediate future. As such, by the time such > an issue came up, I think we would have sufficient operational experience > to deal with that and modify the policy accordingly. I also think that > the oversight by the BOT and their emergency authority could be used to > address any such situation that was detected or brought to their attention. > As such, I think this is reasonably safe discretion to give to the staff > under the current circumstances. They have much wider discretion WRT the > issuance of ASNs and IP addresses than this policy would give them in > preventing the revocation. The point here is that since this policy, as > written, gives staff only the ability to prevent revocation and not the > ability to cause revocation through their discretion, I believe this is > very safe. I disagree, the carrot without the stick is only a prelude to more carrots, and future transgressions.. Yet the stick when not used spoils the child, hence leaving latitude for further abuses to occur or existing abusers to continue unchecked.. However, if the stick has not policy that is strictly and exactly defined, than as you indicate, the stick becomes to often used. Hence my original suggestion that hard and fast rules in the form of a detailed policy is unfortunately necessary... > You and Glenn have convinced me that is the case through your > arguments. If someone presents compelling evidence this is not the case, > I am open to that, but, the evidence you two have presented so far leads > me to that conclusion, and, I am giving you appropriate credit for that. > > > all should have by now learned, such discretion in the past has lead > > to a number of already discussed and debated problems with > > allocation and use of Ipv4 address space. I don't believe that > > these lessons need to be learned again. I hope no one else does > > either. So Owen, I hope you will reconsider your reason for your > > decision based on a more broad thoughtful way. Of course you > > may still arrive at the same decision. >:) > > > Indeed, I believe that is what I did in the first place. I was already > leaning towards support for this policy based on much broader consideration. > Finally, I included the arguments put forth by you and Glenn as additional > input, and, became convinced that the majority of the opposition to the > policy was based on a misinterpretation of the harm this particular form > of discretion could do. As a result, I concluded that support for this > policy was the right thing to do. > > Owen > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit 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 jwkckid1 at ix.netcom.com Mon Apr 18 05:48:04 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 18 Apr 2005 02:48:04 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <426357CB.851CA2A7@ix.netcom.com> <2147483647.1113781597@[172.17.1.152]> Message-ID: <42638252.9DA0EA1F@ix.netcom.com> Owen and all, Owen DeLong wrote: > While I respect and understand your criticism of Jon Postel (that is the > correct spelling of his name, btw), I think you must consider both his > actions, and, the possible or likely actions of ARIN staff in appropriate > context. When Jon was doing what you describe, it was at a time when > virtually anyone could obtain an IP address and there was no expectation > that they would become a scarce resource. I recall speaking with Jon on this matter long before Ip addresses became scarce or at least were becoming scarce. He understood, yet continued his handing out without further concern... He made a understood mistake. Do we want that to reoccur? I would hope and think not.. > Once we started seeing hints > of scarcity and the need for CIDR due to routing table constraints on AGS > boxes (remember those?), he stopped doing that. Yes at this time he finally relented. But at this time he knew long before there would be a problem... Aren't we now considering repeating this same history? It would appear with 2005-2 that we are.. > > > ARIN has never engaged in such behavior, though, technically, I suppose > that certain members of the staff probably have the discretion to do so > if they really chose to. > > However, in the current context of ARIN, there are layers of supervision > within the staff and multiple peer reviews of such discretionary decisions, > so, generally, corruption would require a conspiracy of corrupt individuals. > > Finally, any such discretionary action that was viewed as wrong would, in > all > likelihood be brought before this mailing list by the reporting party who > saw the staff repeatedly refuse to reclaim the resources, as it would be > appropriate at that point to comment that the existing policy was not > working. Wishful thinking I think here.. > > > Again, I just do not see a serious risk to the community from giving the > current ARIN staff this discretion, nor, should the makeup of the staff > change such that it is a concern, do I see this as even in the top 10 issues > related to staff discretion. > > I also believe that by the time that happens, we will be in a much better > position, with much better data to review what changes should be made to > the policy to limit such discretion. Well of course. But isn't this like shutting the barn door after the horse is long gone, and damage has occurred? Shouldn't we anticipate a bit?? Not allot, but a bit?? > > > As such, I think this policy is a good step in the right direction. Let's > put it in place and get some data. When we have an idea of what would make > it better, let's propose a new policy which amends it. That's the whole > point of the ARIN IRPEP and this list. I am always a believe that an ounce of prevention is worth a pound of cure. I guess you are not a proponent of same. > > > Owen > > --On Sunday, April 17, 2005 23:46 -0700 Jeff Williams > wrote: > > > William and all, > > > > Thank you for your reasoned remarks. > > > > I can understand your attitude and concern here. Yet it seems > > more than obvious that discretion needs limits and hence a > > flexible policy seem appropriate that has hard and fast requirements > > regarding reporting, ect. How for instance will it be knowable if > > any ARIN staff member is using good and reasoned discretion? > > Or does one just assume such? > > > > I can for instance remember Jon Postal, god rest his kind soul, > > handing out IPv4 address blocks like they were so much candy > > at halloween. Is that good discretion? Or was it trick and treat? > > > > william(at)elan.net wrote: > > > >> On Sun, 17 Apr 2005, Jeff Williams wrote: > >> > >> > Glenn and all, > >> > > >> > I don't like the idea that the ARIN staff has significant leeway with > >> > regard to discretion. Discretion is a very nebulous thing and can be > >> > easily inappropriately or improperly applied for any number of > >> > reasons. Hence a hard and fast policy for reclaiming resources > >> > is unfortunately necessary. > >> > >> There are a lot of circumstances that can be involved that its difficult > >> to predict by policy text right now. It is probably better that we give > >> ARIN staff some discretion but require them to report on how its been > >> used and if we see that there have been cases that ARIN staff seems > >> to not be applyng "their discretion" in the right way then policy can > >> always be toughened (but already we'd have certain amount of experience > >> and be able to write more detailed policy). This is better then somebody > >> loosing the block because we were too tough and did not account for > >> their special circumstance. > >> > >> >> After ariving in Orlando and getting my registration packets, I read > >> >> Raymond Plzak's 'observations' related to ARIN directory Services & > >> >> Data... I noticed some interesting stuff that made me think more > >> >> about what drives some of my underlying feelings of being > >> >> uncomfortable with the proposed policy (2005-2). From Section 4.1 of > >> >> that document... > >> > >> And for those not attending were can we read those 'observations'? > >> > >> ARIN staff should really work harder on giving equality to availability > >> of documents to all the ARIN policy process participants (no matter if > >> one is attending meeting or not). As it is is, its 2nd time (in last 4 > >> years) that I'm not able to attend the meeting and yet again I see > >> policy-related documents mentioned that only meeting attendees have > >> access to ... > >> > >> -- > >> William Leibzon > >> Elan Networks > >> william at elan.net > > > > 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 > > > > > > -- > If this message was not signed with gpg key 0FE2AA3D, it's probably > a forgery. > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit 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 owen at delong.com Mon Apr 18 04:07:49 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2005 01:07:49 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <42637EE5.3B44F25B@ix.netcom.com> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <2147483647.1113773323@[172.17.1.152]> <4263558C.D7349246@ix.netcom.com> <2147483647.1113780561@[172.17.1.152]> <42637EE5.3B44F25B@ix.netcom.com> Message-ID: <2147483647.1113786469@[172.17.1.152]> Apologies to all if this seems like mostly rehash. I will try not to respond again publicly unless there is significant new information. However, since Jeff still seems to be misunderstanding some of what I intended to say, I felt posting this last clarification was worth the effort. Owen [snip] > Yes and harm has already been inflicted on too many occasions for me > to have kept count... > I don't see how: 1. Harm can have been inflicted under a policy which does not yet exist. 2. This policy grants any discretion which would allow staff to cause harm. The discretion granted in this policy is strictly limited to the ability to prevent harm where it would otherwise be allowed under the policy. In such a new type of policy with such potential to do harm, this seems a reasonable safety valve, IMO. If you are talking about harm done under other policies, then, that is not particularly germane to this discussion unless you can point to some place in this policy that I have missed where the discretion exists for ARIN staff to do additional harm rather than merely prevent it. > Agreed, except if harm has already occurred on multiple occasions, than > the discretion exercised is either not good enough, improperly determined > far to often, or has other motivations for such discretion to be > exercised... > Again, I don't see how this makes sense in the context of discussing this policy. Harm has not already occurred under this policy because this policy does not yet exist. >> The only reason this is a bad idea in law enforcement is that >> it encourages corruption. While, in the long run, it might be possible >> that people would "bribe corrupt ARIN officials to allow them to keep >> their inaccurate data in spite of refusal to correct it.", I don't think >> that is an issue in the immediate future. As such, by the time such >> an issue came up, I think we would have sufficient operational experience >> to deal with that and modify the policy accordingly. I also think that >> the oversight by the BOT and their emergency authority could be used to >> address any such situation that was detected or brought to their >> attention. As such, I think this is reasonably safe discretion to give >> to the staff under the current circumstances. They have much wider >> discretion WRT the issuance of ASNs and IP addresses than this policy >> would give them in preventing the revocation. The point here is that >> since this policy, as written, gives staff only the ability to prevent >> revocation and not the ability to cause revocation through their >> discretion, I believe this is very safe. > > I disagree, the carrot without the stick is only a prelude to more > carrots, and future transgressions.. Yet the stick when not used > spoils the child, hence leaving latitude for further abuses to > occur or existing abusers to continue unchecked.. However, > if the stick has not policy that is strictly and exactly defined, > than as you indicate, the stick becomes to often used. Hence > my original suggestion that hard and fast rules in the form of > a detailed policy is unfortunately necessary... > 1. I don't really understand your meaning here. Generally, I try to avoid viewing the government has having anything close to a parental role in my life. Not that they don't try to usurp such a role on a regular basis, but, it's just not a good place to go. 2. This policy has no carrot and a very limited "stick". If the POC for a resource is completely non-responsive, then, it is quite likely that the resource itself does not remain in legitimate use and should be reclaimed. The discretion granted in this policy is the ability for staff to recognize and prevent an unwarranted revocation that would otherwise occur in this policy. That is, IMO, a prudent safety valve for such an experiment. I could not support such a policy at this time without it. 3. This is about public policy, not disciplining children. If you do not believe that there is a difference, then, we are much further apart in our views than I had hoped, and, I believe we should simply agree to disagree on this matter. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Mon Apr 18 08:01:30 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 18 Apr 2005 05:01:30 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <2147483647.1113773323@[172.17.1.152]> <4263558C.D7349246@ix.netcom.com> <2147483647.1113780561@[172.17.1.152]> <42637EE5.3B44F25B@ix.netcom.com> <2147483647.1113786469@[172.17.1.152]> Message-ID: <4263A192.BC88D05B@ix.netcom.com> Owen and all, I did NOT say ARIN had caused ANY harm. I DID say that harm has already occurred, AND that this proposed policy can ONLY address one avenue by which harm can be caused. So I believe it is you that did not understand what I said, Owen. And perhaps in part that is my fault. I hope now you and/or anyone else is clear as to what, why and how this proposed policy is insufficient IF harm is to be dealt with given lack of policy directives as well as unchecked discretion by the ARIN staff. Else, the same result Jon caused will undoubtedly reoccur all be it to a lessor degree and/or possibly over a longer time frame... Owen DeLong wrote: > Apologies to all if this seems like mostly rehash. I will try not to > respond again publicly unless there is significant new information. > However, since Jeff still seems to be misunderstanding some of what I > intended to say, I felt posting this last clarification was worth > the effort. > > Owen > > [snip] > > Yes and harm has already been inflicted on too many occasions for me > > to have kept count... > > > I don't see how: > 1. Harm can have been inflicted under a policy which does not > yet exist. > > 2. This policy grants any discretion which would allow staff > to cause harm. The discretion granted in this policy is > strictly limited to the ability to prevent harm where it > would otherwise be allowed under the policy. In such a new > type of policy with such potential to do harm, this seems > a reasonable safety valve, IMO. > > If you are talking about harm done under other policies, then, that is not > particularly germane to this discussion unless you can point to some place > in this policy that I have missed where the discretion exists for ARIN staff > to do additional harm rather than merely prevent it. > > > Agreed, except if harm has already occurred on multiple occasions, than > > the discretion exercised is either not good enough, improperly determined > > far to often, or has other motivations for such discretion to be > > exercised... > > > Again, I don't see how this makes sense in the context of discussing this > policy. Harm has not already occurred under this policy because this policy > does not yet exist. > > >> The only reason this is a bad idea in law enforcement is that > >> it encourages corruption. While, in the long run, it might be possible > >> that people would "bribe corrupt ARIN officials to allow them to keep > >> their inaccurate data in spite of refusal to correct it.", I don't think > >> that is an issue in the immediate future. As such, by the time such > >> an issue came up, I think we would have sufficient operational experience > >> to deal with that and modify the policy accordingly. I also think that > >> the oversight by the BOT and their emergency authority could be used to > >> address any such situation that was detected or brought to their > >> attention. As such, I think this is reasonably safe discretion to give > >> to the staff under the current circumstances. They have much wider > >> discretion WRT the issuance of ASNs and IP addresses than this policy > >> would give them in preventing the revocation. The point here is that > >> since this policy, as written, gives staff only the ability to prevent > >> revocation and not the ability to cause revocation through their > >> discretion, I believe this is very safe. > > > > I disagree, the carrot without the stick is only a prelude to more > > carrots, and future transgressions.. Yet the stick when not used > > spoils the child, hence leaving latitude for further abuses to > > occur or existing abusers to continue unchecked.. However, > > if the stick has not policy that is strictly and exactly defined, > > than as you indicate, the stick becomes to often used. Hence > > my original suggestion that hard and fast rules in the form of > > a detailed policy is unfortunately necessary... > > > 1. I don't really understand your meaning here. Generally, I try > to avoid viewing the government has having anything close to a > parental role in my life. Not that they don't try to usurp such > a role on a regular basis, but, it's just not a good place to go. > > 2. This policy has no carrot and a very limited "stick". If the POC > for a resource is completely non-responsive, then, it is quite likely > that the resource itself does not remain in legitimate use and should > be reclaimed. The discretion granted in this policy is the ability > for staff to recognize and prevent an unwarranted revocation that > would otherwise occur in this policy. That is, IMO, a prudent safety > valve for such an experiment. I could not support such a policy > at this time without it. > > 3. This is about public policy, not disciplining children. If you do > not believe that there is a difference, then, we are much further > apart in our views than I had hoped, and, I believe we should simply > agree to disagree on this matter. > > Owen > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit 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 Mon Apr 18 06:23:22 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 18 Apr 2005 11:23:22 +0100 Subject: [ppml] comments on 2004-8 In-Reply-To: Message-ID: > >If we are going to be making modifications to this one, > >then I think it is time to say that these announcements > >and web accessible documents should be in a machine-parseable > >format. Something like RSS could be used or even just a plain > >XML page. The current IANA list of address ranges is not > >machine parseable and is not consistent from range to range. > >There is no good reason why the list of ranges produced by > >IANA should be broken (or aggregated) on class A boundaries. > >If they have this info in a database, then it should be > >trivial to report it as an XML file. > > As far as policy is concerned, I don't think that the details of the > formatting, etc., are that important. I'd say that it is covered in > the "will establish administrative procedures" phrase. (My comments > are related to the flow of the announcements, not the contents of the > announcements.) > > IANA's choice of data format isn't an ARIN problem, so I wouldn't > attach that to this proposal in this arena. This "arena" is not just for discussing ARIN policy text. That's why I brought up the issue here. And while it is not appropriate for ARIN to make a policy telling IANA what to do, it is certainly appropriate for any interested party to post to this list and tell IANA to publish their data in a machine parseable format such as RPSL or XML or both. IANA is broke, let's fix it! --Michael Dillon From Michael.Dillon at radianz.com Mon Apr 18 06:28:52 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 18 Apr 2005 11:28:52 +0100 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <20050415185704.GA95722@ussenterprise.ufp.org> Message-ID: > There are literally several hundred federal laws that deal with > privacy in various circumstances, and if you throw in the state, > province, and city laws you could realistically be looking at over > 10,000 or even over 100,000 laws affecting privacy inside the ARIN > region. What's more, many of them are conditional on various other > criteria. Examples include Canada, where you can't publish information > without consent of the party who's information is being published, > or the Children's Online Protection Act, which prevents you from > publishing information on people under the age of 13, or under 18 > without parents consent. Is it reasonable for ARIN to require an > ISP to obtain consent in these cases? Is it reasonable to deny > someone under the age of 13 IP addresses because they cannot have > their information published? You've just made a good case for ARIN to stop publishing any data that is not directly relevant to Internet operations. Bye, bye whois! In fact, it would be a darn good idea to get into compliance with Canadian law and only publish whois data about organizations who explicitly consent to have that data published. Since ARIN allocations require siging an agreement with ARIN, this can be bundled into that agreement. That gives us the top level of the chain of authority for IP address blocks. If any of those companies think that they should not be 100% responsible for their customers' use of the blocks, then it should be up to them to get the customer's permission to publish data. And in the process, they will be able to make sure that they have the CORRECT contact information. Hallelujah! --Michael Dillon From gih at apnic.net Mon Apr 18 06:41:32 2005 From: gih at apnic.net (Geoff Huston) Date: Mon, 18 Apr 2005 20:41:32 +1000 Subject: [ppml] comments on 2004-8 In-Reply-To: References: Message-ID: <6.0.1.1.2.20050418203601.03a25da0@localhost> >This "arena" is not just for discussing ARIN policy text. That's >why I brought up the issue here. And while it is not appropriate >for ARIN to make a policy telling IANA what to do, it is certainly >appropriate for any interested party to post to this list and >tell IANA to publish their data in a machine parseable format >such as RPSL or XML or both. yep! From the Internet draft: draft-huston-ip6-iana-registry-05.txt (in RFC Editor Queue) "The proposed format for the IANA registry is a small step towards the creation of a registry that can be used as a trust point for commencing a chain of address validation. Consideration should be given to IANA registry publication formats that are machine parseable, and also the use of file signatures and associated certificate mechanisms to allow applications to confirm that the registry contents are current, and that they have been published by the IANA." As one of a number of folk who attempt to parse some of these IANA registries, it would certainly be useful to have equivalent machine parseable forms of these registries. A modest attempt to generate an equivalent form of the IPv4, IPv6 and AS registries in the same format as the RIR stats files can be found at http://bgp.potaroo.net/stats/iana/delegated XML would also be of assistance to allow for a more stable form of reading this IANA information. regards, Geoff From owen at delong.com Mon Apr 18 07:25:23 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2005 04:25:23 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <4263A192.BC88D05B@ix.netcom.com> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <2147483647.1113773323@[172.17.1.152]> <4263558C.D7349246@ix.netcom.com> <2147483647.1113780561@[172.17.1.152]> <42637EE5.3B44F25B@ix.netcom.com> <2147483647.1113786469@[172.17.1.152]> <4263A192.BC88D05B@ix.netcom.com> Message-ID: <2147483647.1113798323@[172.17.1.152]> --On Monday, April 18, 2005 5:01 -0700 Jeff Williams wrote: > Owen and all, > > I did NOT say ARIN had caused ANY harm. I DID say that > harm has already occurred, AND that this proposed policy can > ONLY address one avenue by which harm can be caused. > Fair enough... > So I believe it is you that did not understand what I said, Owen. > And perhaps in part that is my fault. I hope now you and/or > anyone else is clear as to what, why and how this proposed > policy is insufficient IF harm is to be dealt with given lack > of policy directives as well as unchecked discretion by the > ARIN staff. Else, the same result Jon caused will undoubtedly > reoccur all be it to a lessor degree and/or possibly over a longer > time frame... > You are right... This policy, and, every other ARIN policy does not cure all the worlds woes. The best we can seek in any policy proposal is an incremental improvement over the current situation. When deciding whether to support a policy or not, I tend to evaluate it on the basis of "Is this better than what we have now?" If the answer to that question is a clear yes, as I believe it to be with this policy, then, I will support the policy. Are there problems this policy doesn't address? Sure. Are there areas of this problem for which this policy is inadequate? Sure. Is there any area where this policy is worse than the current policy? I don't believe so. Is it better than what we have now? Yes. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From bicknell at ufp.org Mon Apr 18 08:01:22 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 18 Apr 2005 08:01:22 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <426357CB.851CA2A7@ix.netcom.com> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <426357CB.851CA2A7@ix.netcom.com> Message-ID: <20050418120122.GA5350@ussenterprise.ufp.org> In a message written on Sun, Apr 17, 2005 at 11:46:37PM -0700, Jeff Williams wrote: > I can understand your attitude and concern here. Yet it seems > more than obvious that discretion needs limits and hence a > flexible policy seem appropriate that has hard and fast requirements > regarding reporting, ect. How for instance will it be knowable if > any ARIN staff member is using good and reasoned discretion? > Or does one just assume such? While the ARIN staff has some leeway in the policy as proposed, the policy clearly requires ARIN to document the process they will use on the ARIN public web site before implementing the plan. The discretion is that the staff can construct the process in the most efficient manor for them and for the ARIN members. Since it will be clearly and publically posted before it can be implemented if the ARIN staff somehow abuses their discretion (which I consider highly unlikely, as Owen points out they are more likely to err on the side of not acting, rather than acting too much) in the construction of the procedure there will be an opportunity for public outcry after it's posted but before the policy is actually implemented. -- 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 iggy at merit.edu Mon Apr 18 09:27:59 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Mon, 18 Apr 2005 09:27:59 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <2147483647.1113746839@imac-en0.delong.sj.ca.us> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <2147483647.1113746839@imac-en0.delong.sj.ca.us> Message-ID: Actualy I think there are ligitamate reasons that a POC may not be responsive for as many as 3 months. The policy proposal is unclear if this must be consecutive months or not, but this too is somewhat irrelevant. Consider a small special purpose school that may not operate for the whole summer. Glenn Wiltse On Sun, 17 Apr 2005, Owen DeLong wrote: > > Let me get back to a specific part of this policy proposal that I don't > > like... > > > > "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." I belive that there are > > > > I suggest to you that there can be valid re-assignments of ARIN > > resources, that may for a varitey of reasons become non-responsive for > > preiods of a month or longer, and should not constitute anything close to > > being grounds for reclaimation or maybe not even be grounds for > > 'suspension'(depending on how that is defined). Consider something such > > as a seasonal business, or a very small busines where possibly the entire > > staff is gone for a month or more. (possibly a small family based > > business, etc...) Well, you say ARIN staff can use there 'discretion' to > > determin that this is something that doesn't constitute a offense. I say > > that there shouldn't be room for ARIN staffs descretion... The only reason > > for reclaiming resources based on 'inaccurate' or 'non responsive' > > contacts, is FRAUD, which is legaly defined. > > > And it doesn't... It requires 4 times per month for three months. There's > no > legitimate reason for a valid POC for a network resource to be unreachable > for 3 months solid. A Seasonal business should have a responsive backup > POC from their upstream or such. Otherwise, the rest of the world is > expected to live with their resources being abused while they aren't > looking? > I think that is bad for the world. > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. > From memsvcs at arin.net Mon Apr 18 09:52:12 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 18 Apr 2005 09:52:12 -0400 Subject: [ppml] Suspended - Policy for the African Portion of the ARIN Region Message-ID: <20050418135226.24E8B1FE8D@mercury.arin.net> Section 4.8, Policy for the African Portion of the ARIN Region, of the ARIN Number Resource Policy Manual is suspended effective today, April 18, 2005. On March 8, 2005, the ARIN Board of Trustees accepted the recommendation from the ARIN Advisory Council to suspend section 4.8 of the Number Resource Policy Manual upon ICANN's recognition of AfriNIC as an RIR. On April 8, 2005, ICANN granted AfriNIC formal recognition as an RIR. Formal removal of section 4.8 from the NRPM will proceed in accordance with the ARIN Internet Resource Policy Evaluation Process. ARIN Board minutes are available at: http://www.arin.net/meetings/minutes/bot/bot2005_0308.html Advisory Council minutes are available at: http://www.arin.net/meetings/minutes/ac/ac2005_0303.html The Number Resource Policy Manual is available at: http://www.arin.net/policy/index.html IRPEP is available at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) From Michael.Dillon at radianz.com Mon Apr 18 10:04:04 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 18 Apr 2005 15:04:04 +0100 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: Message-ID: > Actualy I think there are ligitamate reasons that a POC may not be > responsive for as many as 3 months. The policy proposal is unclear if this > must be consecutive months or not, but this too is somewhat irrelevant. > Consider a small special purpose school that may not operate for the whole > summer. There's another good reason why it is bad policy to publish contact info for every organization receiving an address block. That may have been a good idea in 1990 when every organization receiving addresses was an active network operator. But in today's world, where most organizations receiving addresses are little more than consumers, this is a BAD policy. ARIN should never publish any contact information for an organization which does not explicitly agree with ARIN that its contact information should be published. In your example above, the ISP providing service to this school would be a far more appropriate contact point than the school itself. But archaic blanket policies do not allow for cases like this. --Michael Dillon From Ed.Lewis at neustar.biz Mon Apr 18 11:16:18 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 18 Apr 2005 11:16:18 -0400 Subject: [ppml] Impacts statements Message-ID: I like seeing that there are staff and legal impacts being presented along with the policy proposals. However, it would be good to have the impact statements available in advance. I'd propose something like - prior to a meeting, at the time of announcing the policy proposals for a meeting (like http://www.arin.net/mailing_lists/arin-announce/0430.html), it would be helpful to have the impacts available and announced then. This is a balance between the need to have time to review the impacts and not having the staff research less-than-half-baked proposals. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From iggy at merit.edu Mon Apr 18 11:28:09 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Mon, 18 Apr 2005 11:28:09 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: Message-ID: In Michigan, and I'm sure elsewhere... there are Speical Function Special Purpose schools that do not belong to ISDs. I know at least one where the staff is more or less a husband and wife who operate the school. The SFSP school is really just one example, there could be others where POCs for reassigned resources could be un-responsive for long periods of time, yet the data is not nessasarly invalid, or fraudulent. As the ISP providing service to some of these very small schools and other tiny originization or individuals, we often want the first line of contact for these types of customers to be someone close to our customers LAN. We want the information public... We consider it to be valid data, and want you to try and resolve any issues with them whenever possible. If you can not make contact with a POC that we've listed with a reassignmet, then you are weclome to contact us, and we will respond. Furthermore, if you do find some data that is inaccurate for one of our reassignments, we will correct it. The contacts for a ISP's customer(reassignments of ARIN resources) are not nessasarly inaccurate if they do not respond in some fixed amount of time. Glenn Wiltse On Mon, 18 Apr 2005 Michael.Dillon at radianz.com wrote: > > Actualy I think there are ligitamate reasons that a POC may not be > > responsive for as many as 3 months. The policy proposal is unclear if > this > > must be consecutive months or not, but this too is somewhat irrelevant. > > Consider a small special purpose school that may not operate for the > whole > > summer. > > There's another good reason why it is bad policy to publish > contact info for every organization receiving an address > block. That may have been a good idea in 1990 when every > organization receiving addresses was an active network > operator. But in today's world, where most organizations > receiving addresses are little more than consumers, this > is a BAD policy. ARIN should never publish any contact > information for an organization which does not explicitly > agree with ARIN that its contact information should be published. > > In your example above, the ISP providing service to this > school would be a far more appropriate contact point > than the school itself. But archaic blanket policies > do not allow for cases like this. > > --Michael Dillon > > > !DSPAM:4263be86858437312325! > > From Ed.Lewis at neustar.biz Mon Apr 18 14:38:01 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 18 Apr 2005 14:38:01 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: Message-ID: At 15:04 +0100 4/18/05, Michael.Dillon at radianz.com wrote: >ARIN should never publish any contact >information for an organization which does not explicitly >agree with ARIN that its contact information should be published. There's something intriguing in that statement. Having been exposed to the way gTLDs are run under ICANN, I have come to see that the relationship between registries and registrars conforming to the shared registry model has some relevance to the relationship between ARIN and ISPs, or RIRs and NIRs/LIRs/ISPs in other regions. One of the aspects of the relationship is where information is collected, stored and published. In the shared registry model, all information from registrants is collected by registrars, there is no direct (business) relationship between the registry and registrant. This is akin to "provider assigned" address space. It's important to keep in mind that not all name registries operate according to ICANN's shared registry model. Some registries still go directly to the registrant, some use a mix. In some cases, there's the concept of a "registrar of last resort" offered by the registry. The latter is akin to the legacy or "provider independent" space. (I may be glossing over crucial details...) Coming back to the comment above, one of the design points in shared registries is whether the contact information, etc., is maintained at the registrars and only the DNS-relevant (for lack of a better term) is propagated to the registry. This is called a "thin registry." A "thick registry" means that all information, contact, DNS, etc., is propagated to the registry. There are debates as to which approach is better. I'll pick on one advantage of thick registry though - that all of the information collected is in one place, which is a benefit if one of the registrar/ISP goes out of business. In the name arena, this could be significant. Maybe this isn't as important in the number arena - if you're ISP goes belly up, does it matter that you retain your provider assigned address space? (Folks might say yes.) What this might lead to is the idea that ARIN collects all information from the ISPs, as it does now. This relates only to collection though - I haven't addresses publication, aka disclosure, which is the hot button. It could be that ARIN collects everything, but only in an "escrow" function. Responsibility for disclosure of "down streamer" information may lie with the ISP - meaning now that the ISP has to do this (or somehow relies on ARIN for this). WhoIs hasn't been good at referrals, this is where a tool like IRIS comes in. (I won't dignify RWhoIs here. ;)) Besides being able to support a thick or thin, or a combo thick/thin model registry, IRIS is also able to support richer disclosure policies. I think that is also an important point for ARIN. This is just one aspect of the directory service work to be done. IRIS needs some work - the IETF hasn't finalized the document defining the schema for address registries. The basic protocol doc is done, as well as the domain name schema. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owen at delong.com Mon Apr 18 16:18:06 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2005 13:18:06 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <2147483647.1113746839@imac-en0.delong.sj.ca.us> Message-ID: <2147483647.1113830286@imac-en0.delong.sj.ca.us> --On Monday, April 18, 2005 9:27 AM -0400 Glenn Wiltse wrote: > Actually I think there are ligitamate reasons that a POC may not be > responsive for as many as 3 months. The policy proposal is unclear if this > must be consecutive months or not, but this too is somewhat irrelevant. > Consider a small special purpose school that may not operate for the whole > summer. > Such a school should have at lesat one POC which will accept responsibility for addressing abuse complaints while they are closed. If they have to contract with their usptream to achieve this, so be it. Really, what is the likelihood such a school would have a direct ARIN assignment/allocation? Why should the world live with indefinite periods of abuse? Owen > Glenn Wiltse > > On Sun, 17 Apr 2005, Owen DeLong wrote: >> > Let me get back to a specific part of this policy proposal that I > don't >> > like... >> > >> > "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." I >> > belive that there are >> > >> > I suggest to you that there can be valid re-assignments of ARIN >> > resources, that may for a varitey of reasons become non-responsive for >> > preiods of a month or longer, and should not constitute anything close >> > to being grounds for reclaimation or maybe not even be grounds for >> > 'suspension'(depending on how that is defined). Consider something >> > such as a seasonal business, or a very small busines where possibly >> > the entire staff is gone for a month or more. (possibly a small family >> > based business, etc...) Well, you say ARIN staff can use there >> > 'discretion' to determin that this is something that doesn't >> > constitute a offense. I say that there shouldn't be room for ARIN >> > staffs descretion... The only reason for reclaiming resources based on >> > 'inaccurate' or 'non responsive' contacts, is FRAUD, which is legaly >> > defined. >> > >> And it doesn't... It requires 4 times per month for three months. >> There's no >> legitimate reason for a valid POC for a network resource to be >> unreachable for 3 months solid. A Seasonal business should have a >> responsive backup POC from their upstream or such. Otherwise, the rest >> of the world is expected to live with their resources being abused while >> they aren't looking? >> I think that is bad for the world. >> >> Owen >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. >> -- 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 Mon Apr 18 16:19:06 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2005 13:19:06 -0700 Subject: [ppml] Suspended - Policy for the African Portion of the ARIN Region In-Reply-To: <20050418135226.24E8B1FE8D@mercury.arin.net> References: <20050418135226.24E8B1FE8D@mercury.arin.net> Message-ID: <2147483647.1113830346@imac-en0.delong.sj.ca.us> I support the removal of section 4.8 and congratulations to AfriNIC. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From iggy at merit.edu Mon Apr 18 16:33:24 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Mon, 18 Apr 2005 16:33:24 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <2147483647.1113830286@imac-en0.delong.sj.ca.us> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <2147483647.1113746839@imac-en0.delong.sj.ca.us> <2147483647.1113830286@imac-en0.delong.sj.ca.us> Message-ID: In my senerio, there are alternate contacts, they are the upstreem provider's POCs. There should be no need to place an addtional POC on the orginization that gets the reassigned resources, since it's already clear that the upstreem provider is ultimately responsible. I never said anything about living with unlimited periods of abuse. I wouldn't be willing to accept that. The current policy proposal doesn't differentiate between 'non responsive' POCs that receive direct ARIN resources, and those that do not. If this policy proposal only applied to POCs tied to ORGs that get direct allocations or assignments from ARIN I would not argue the point. GLenn Wiltse On Mon, 18 Apr 2005, Owen DeLong wrote: > > > --On Monday, April 18, 2005 9:27 AM -0400 Glenn Wiltse > wrote: > > > Actually I think there are ligitamate reasons that a POC may not be > > responsive for as many as 3 months. The policy proposal is unclear if this > > must be consecutive months or not, but this too is somewhat irrelevant. > > Consider a small special purpose school that may not operate for the whole > > summer. > > > Such a school should have at lesat one POC which will accept responsibility > for addressing abuse complaints while they are closed. If they have to > contract with their usptream to achieve this, so be it. Really, what is > the likelihood such a school would have a direct ARIN assignment/allocation? > > Why should the world live with indefinite periods of abuse? > > Owen > > > Glenn Wiltse > > > > On Sun, 17 Apr 2005, Owen DeLong wrote: > >> > Let me get back to a specific part of this policy proposal that I > > don't > >> > like... > >> > > >> > "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." I > >> > belive that there are > >> > > >> > I suggest to you that there can be valid re-assignments of ARIN > >> > resources, that may for a varitey of reasons become non-responsive for > >> > preiods of a month or longer, and should not constitute anything close > >> > to being grounds for reclaimation or maybe not even be grounds for > >> > 'suspension'(depending on how that is defined). Consider something > >> > such as a seasonal business, or a very small busines where possibly > >> > the entire staff is gone for a month or more. (possibly a small family > >> > based business, etc...) Well, you say ARIN staff can use there > >> > 'discretion' to determin that this is something that doesn't > >> > constitute a offense. I say that there shouldn't be room for ARIN > >> > staffs descretion... The only reason for reclaiming resources based on > >> > 'inaccurate' or 'non responsive' contacts, is FRAUD, which is legaly > >> > defined. > >> > > >> And it doesn't... It requires 4 times per month for three months. > >> There's no > >> legitimate reason for a valid POC for a network resource to be > >> unreachable for 3 months solid. A Seasonal business should have a > >> responsive backup POC from their upstream or such. Otherwise, the rest > >> of the world is expected to live with their resources being abused while > >> they aren't looking? > >> I think that is bad for the world. > >> > >> Owen > >> > >> -- > >> If it wasn't crypto-signed, it probably didn't come from me. > >> > > > > -- > If it wasn't crypto-signed, it probably didn't come from me. > From owen at delong.com Mon Apr 18 16:32:42 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2005 13:32:42 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: Message-ID: <2147483647.1113831162@imac-en0.delong.sj.ca.us> However, Glenn, in that case, the fact that we can contact you should be listed as an additional contact in that reassignment. In that case, ARIN would contact you and find that information out, and, under the proposed policy, nothing would happen. The point is that if _ALL_ of the contacts for a resource remain unreachable for an extended period of time (3 months seems more than reasonable), there needs to be some way to address that. Nothing prevents you from listing your ISP as one of the contacts in the reassignment data. Owen --On Monday, April 18, 2005 11:28 AM -0400 Glenn Wiltse wrote: > > In Michigan, and I'm sure elsewhere... there are Speical Function > Special Purpose schools that do not belong to ISDs. I know at least one > where the staff is more or less a husband and wife who operate the school. > > The SFSP school is really just one example, there could be others > where POCs for reassigned resources could be un-responsive for long > periods of time, yet the data is not nessasarly invalid, or fraudulent. > > As the ISP providing service to some of these very small schools and > other tiny originization or individuals, we often want the first line of > contact for these types of customers to be someone close to our customers > LAN. We want the information public... We consider it to be valid data, > and want you to try and resolve any issues with them whenever possible. If > you can not make contact with a POC that we've listed with a reassignmet, > then you are weclome to contact us, and we will respond. Furthermore, if > you do find some data that is inaccurate for one of our reassignments, we > will correct it. > > The contacts for a ISP's customer(reassignments of ARIN resources) are > not nessasarly inaccurate if they do not respond in some fixed amount of > time. > > Glenn Wiltse > > On Mon, 18 Apr 2005 Michael.Dillon at radianz.com wrote: > >> > Actually I think there are ligitamate reasons that a POC may not be >> > responsive for as many as 3 months. The policy proposal is unclear if >> this >> > must be consecutive months or not, but this too is somewhat irrelevant. >> > Consider a small special purpose school that may not operate for the >> whole >> > summer. >> >> There's another good reason why it is bad policy to publish >> contact info for every organization receiving an address >> block. That may have been a good idea in 1990 when every >> organization receiving addresses was an active network >> operator. But in today's world, where most organizations >> receiving addresses are little more than consumers, this >> is a BAD policy. ARIN should never publish any contact >> information for an organization which does not explicitly >> agree with ARIN that its contact information should be published. >> >> In your example above, the ISP providing service to this >> school would be a far more appropriate contact point >> than the school itself. But archaic blanket policies >> do not allow for cases like this. >> >> --Michael Dillon >> >> >> !DSPAM:4263be86858437312325! >> >> -- 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 Mon Apr 18 18:12:14 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2005 15:12:14 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <2147483647.1113746839@imac-en0.delong.sj.ca.us> <2147483647.1113830286@imac-en0.delong.sj.ca.us> Message-ID: <2147483647.1113837134@imac-en0.delong.sj.ca.us> All ARIN policies, especially WRT reclamation and such can, by definition only apply to direct allocations and assignments. The only thing ARIN can do to affect downstreams is make it part of the conditions of the allocation that the recipient enforce the same rules on the recipients of reassignments. As such, I don't see how or why you think that is not the case with the current proposal. Owen --On Monday, April 18, 2005 4:33 PM -0400 Glenn Wiltse wrote: > In my senerio, there are alternate contacts, they are the upstreem > provider's POCs. There should be no need to place an additional POC > on theorganizationn that gets the reassigned resources, since it's > already clear that the upstreem provider is ultimately responsible. > > I never said anything about living with unlimited periods of abuse. > I wouldn't be willing to accept that. > > The current policy proposal doesn't differentiate between 'non > responsive' POCs that receive direct ARIN resources, and those that do > not. If this policy proposal only applied to POCs tied to ORGs that get > direct allocations or assignments from ARIN I would not argue the point. > > GLenn Wiltse > > On Mon, 18 Apr 2005, Owen DeLong wrote: > >> >> >> --On Monday, April 18, 2005 9:27 AM -0400 Glenn Wiltse >> wrote: >> >> > Actually I think there are ligitamate reasons that a POC may not be >> > responsive for as many as 3 months. The policy proposal is unclear if >> > this must be consecutive months or not, but this too is somewhat >> > irrelevant. Consider a small special purpose school that may not >> > operate for the whole summer. >> > >> Such a school should have at lesat one POC which will accept >> responsibility for addressing abuse complaints while they are closed. >> If they have to contract with their usptream to achieve this, so be it. >> Really, what is the likelihood such a school would have a direct ARIN >> assignment/allocation? >> >> Why should the world live with indefinite periods of abuse? >> >> Owen >> >> > Glenn Wiltse >> > >> > On Sun, 17 Apr 2005, Owen DeLong wrote: >> >> > Let me get back to a specific part of this policy proposal that I >> > don't >> >> > like... >> >> > >> >> > "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." I belive that there are >> >> > >> >> > I suggest to you that there can be valid re-assignments of ARIN >> >> > resources, that may for a varitey of reasons become non-responsive >> >> > for preiods of a month or longer, and should not constitute >> >> > anything close to being grounds for reclaimation or maybe not even >> >> > be grounds for 'suspension'(depending on how that is defined). >> >> > Consider something such as a seasonal business, or a very small >> >> > busines where possibly the entire staff is gone for a month or >> >> > more. (possibly a small family based business, etc...) Well, you >> >> > say ARIN staff can use there 'discretion' to determin that this is >> >> > something that doesn't constitute a offense. I say that there >> >> > shouldn't be room for ARIN staffs descretion... The only reason for >> >> > reclaiming resources based on 'inaccurate' or 'non responsive' >> >> > contacts, is FRAUD, which is legaly defined. >> >> > >> >> And it doesn't... It requires 4 times per month for three months. >> >> There's no >> >> legitimate reason for a valid POC for a network resource to be >> >> unreachable for 3 months solid. A Seasonal business should have a >> >> responsive backup POC from their upstream or such. Otherwise, the >> >> rest of the world is expected to live with their resources being >> >> abused while they aren't looking? >> >> I think that is bad for the world. >> >> >> >> Owen >> >> >> >> -- >> >> If it wasn't crypto-signed, it probably didn't come from me. >> >> >> >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. >> -- 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 jwkckid1 at ix.netcom.com Tue Apr 19 01:52:02 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 18 Apr 2005 22:52:02 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <2147483647.1113773323@[172.17.1.152]> <4263558C.D7349246@ix.netcom.com> <2147483647.1113780561@[172.17.1.152]> <42637EE5.3B44F25B@ix.netcom.com> <2147483647.1113786469@[172.17.1.152]> <4263A192.BC88D05B@ix.netcom.com> <2147483647.1113798323@[172.17.1.152]> Message-ID: <42649C7E.30A0352E@ix.netcom.com> Owen and all, Owen dealing wrote: > --On Monday, April 18, 2005 5:01 -0700 Jeff Williams > wrote: > > > Owen and all, > > > > I did NOT say ARIN had caused ANY harm. I DID say that > > harm has already occurred, AND that this proposed policy can > > ONLY address one avenue by which harm can be caused. > > > Fair enough... > > > So I believe it is you that did not understand what I said, Owen. > > And perhaps in part that is my fault. I hope now you and/or > > anyone else is clear as to what, why and how this proposed > > policy is insufficient IF harm is to be dealt with given lack > > of policy directives as well as unchecked discretion by the > > ARIN staff. Else, the same result Jon caused will undoubtedly > > reoccur all be it to a lessor degree and/or possibly over a longer > > time frame... > > > You are right... This policy, and, every other ARIN policy does not > cure all the worlds woes. The best we can seek in any policy proposal > is an incremental improvement over the current situation. When deciding > whether to support a policy or not, I tend to evaluate it on the basis > of "Is this better than what we have now?" If the answer to that question > is a clear yes, as I believe it to be with this policy, then, I will > support the policy. I did not suggest that this or any other proposed or existing policy is a cure all for the worlds problems. Hence your characterization above is inconsistent with anything I have said.. It is true that an incremental policy proposal such as 2005-2 is an minor improvement in one particular area or method. It also has as we have debated and discussed, several flaws regarding discretion and use of same. As such use is not defined even generally, discretion can be determined on a case by case basis, which is fine unless there is pronounced and identified actions that would direct otherwise. Lacking such language in this proposed policy, the potential for continued misuse of a resource [ Ipv4 ] in this case, remains available and largely not correctable given this policy proposal.. > > > Are there problems this policy doesn't address? Sure. Are there areas > of this problem for which this policy is inadequate? Sure. Is there > any area where this policy is worse than the current policy? I don't > believe so. Is it better than what we have now? Yes. > > Owen > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit 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 jwkckid1 at ix.netcom.com Tue Apr 19 01:55:35 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 18 Apr 2005 22:55:35 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <4263347A.45F5D1B2@ix.netcom.com> <426357CB.851CA2A7@ix.netcom.com> <20050418120122.GA5350@ussenterprise.ufp.org> Message-ID: <42649D56.CCD7458D@ix.netcom.com> Leo and all, Understood. However not acting appropriately and promptly in some instances is as bad as over acting. Hence the need to define in a hard and fast manner as part of this policy what constitutes when and for what reasons a direct and prompt action is necessary IMHO... Leo Bicknell wrote: > In a message written on Sun, Apr 17, 2005 at 11:46:37PM -0700, Jeff Williams wrote: > > I can understand your attitude and concern here. Yet it seems > > more than obvious that discretion needs limits and hence a > > flexible policy seem appropriate that has hard and fast requirements > > regarding reporting, ect. How for instance will it be knowable if > > any ARIN staff member is using good and reasoned discretion? > > Or does one just assume such? > > While the ARIN staff has some leeway in the policy as proposed, the > policy clearly requires ARIN to document the process they will use > on the ARIN public web site before implementing the plan. The > discretion is that the staff can construct the process in the most > efficient manor for them and for the ARIN members. Since it will > be clearly and publically posted before it can be implemented if > the ARIN staff somehow abuses their discretion (which I consider > highly unlikely, as Owen points out they are more likely to err on > the side of not acting, rather than acting too much) in the > construction of the procedure there will be an opportunity for > public outcry after it's posted but before the policy is actually > implemented. > > -- > 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 > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature 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 jwkckid1 at ix.netcom.com Tue Apr 19 02:04:45 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 18 Apr 2005 23:04:45 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <2147483647.1113746839@imac-en0.delong.sj.ca.us> Message-ID: <42649F7A.88CC14AF@ix.netcom.com> Glenn and all, Good point. Yet this fictitious school you use as a very reasonable example still should have valid and contactable contact information avaliable/listed for their assigned Ipv4 resources. It is not reasonably conceivable that no contact can be made for a period of longer than 15 days IMHO, unless there is a death of the contact person in that period, or that person is so ill as to be unable to respond. In even in both of these special conditions, and alternative or backup contact person should be available... Glenn Wiltse wrote: > Actualy I think there are ligitamate reasons that a POC may not be > responsive for as many as 3 months. The policy proposal is unclear if this > must be consecutive months or not, but this too is somewhat irrelevant. > Consider a small special purpose school that may not operate for the whole > summer. > > Glenn Wiltse > > On Sun, 17 Apr 2005, Owen DeLong wrote: > > > Let me get back to a specific part of this policy proposal that I > don't > > > like... > > > > > > "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." I belive that there are > > > > > > I suggest to you that there can be valid re-assignments of ARIN > > > resources, that may for a varitey of reasons become non-responsive for > > > preiods of a month or longer, and should not constitute anything close to > > > being grounds for reclaimation or maybe not even be grounds for > > > 'suspension'(depending on how that is defined). Consider something such > > > as a seasonal business, or a very small busines where possibly the entire > > > staff is gone for a month or more. (possibly a small family based > > > business, etc...) Well, you say ARIN staff can use there 'discretion' to > > > determin that this is something that doesn't constitute a offense. I say > > > that there shouldn't be room for ARIN staffs descretion... The only reason > > > for reclaiming resources based on 'inaccurate' or 'non responsive' > > > contacts, is FRAUD, which is legaly defined. > > > > > And it doesn't... It requires 4 times per month for three months. There's > > no > > legitimate reason for a valid POC for a network resource to be unreachable > > for 3 months solid. A Seasonal business should have a responsive backup > > POC from their upstream or such. Otherwise, the rest of the world is > > expected to live with their resources being abused while they aren't > > looking? > > I think that is bad for the world. > > > > Owen > > > > -- > > If it wasn't crypto-signed, it probably didn't come from me. > > 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 jwkckid1 at ix.netcom.com Tue Apr 19 02:11:40 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 18 Apr 2005 23:11:40 -0700 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul References: Message-ID: <4264A119.807B1A0C@ix.netcom.com> Michael and all, Another good point Michael! Still contact information of some sort is necessary. However making such contact information not publicly available in a whois look-up is easily achieved. Yet RIR/ARIN staff's of appropriate sort will/should be able to view said contact information... A maximum of privacy protection should be provided the resource owner/holder that is technically possible... Michael.Dillon at radianz.com wrote: > > Actualy I think there are ligitamate reasons that a POC may not be > > responsive for as many as 3 months. The policy proposal is unclear if > this > > must be consecutive months or not, but this too is somewhat irrelevant. > > Consider a small special purpose school that may not operate for the > whole > > summer. > > There's another good reason why it is bad policy to publish > contact info for every organization receiving an address > block. That may have been a good idea in 1990 when every > organization receiving addresses was an active network > operator. But in today's world, where most organizations > receiving addresses are little more than consumers, this > is a BAD policy. ARIN should never publish any contact > information for an organization which does not explicitly > agree with ARIN that its contact information should be published. > > In your example above, the ISP providing service to this > school would be a far more appropriate contact point > than the school itself. But archaic blanket policies > do not allow for cases like this. > > --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 memsvcs at arin.net Tue Apr 19 08:57:34 2005 From: memsvcs at arin.net (Member Services) Date: Tue, 19 Apr 2005 08:57:34 -0400 Subject: [ppml] ARIN Public Policy Meeting Day Two: Webcast and Remote Participation Available Message-ID: <4265003E.4070709@arin.net> Day two of the ARIN Public Policy Meeting in Orlando begins at 9:00 AM this morning. The meeting will open with a discussion of Policy Proposal 2005-2, Directory Services Overhaul. Please note the revised agenda at: http://www.arin.net/ARIN-XV/tuesday.html Details on how to view the webcast are available at: http://www.arin.net/ARIN-XV/webcast.html If you wish to participate remotely, please send an e-mail to: remote at arin.net and follow the instructions in the return e-mail from ARIN. Regards, Member Services American Registry for Internet Numbers (ARIN) From jdhoule at att.com Tue Apr 19 09:54:52 2005 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Tue, 19 Apr 2005 08:54:52 -0500 Subject: [ppml] Policy Proposal 2004-3 point of order Message-ID: Folks: This may be more of a point of order, then a technical comment. This proposal has been positioned as a clarification not a change in policy. And I expect the result of the "vote" yesterday was primarily driven by that assertion. Let's ask a question and see how one might interpret policy under the old wording and new wording. Question: Will ARIN provide globally unique addresses to an entity that has no intention of advertising those addresses out to the Internet or making those addresses reachable from the Internet. Old wording: I suggest most folks would interpret the wording as "no". New wording: I suggest most would interpret the new wording as "yes". This sounds like a change in policy, not a clarification. I'm not sure the mandate from yesterday's vote is to change the policy. Joe Houle -------------- next part -------------- An HTML attachment was scrubbed... URL: From marla_azinger at eli.net Tue Apr 19 10:13:01 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Tue, 19 Apr 2005 07:13:01 -0700 Subject: [ppml] Policy Proposal 2004-3 point of order Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20151216B@wava00s2ke2k01.corp.pvt> Well if you interpreted it to mean "no" in the past. Then you were interpreting it wrong (hence the clarification). The execution of this policy has never denied it from either a company that did or did not intend to make them go "public". -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Houle, Joseph D (Joe), CMO Sent: Tuesday, April 19, 2005 6:55 AM To: ppml at arin.net Subject: [ppml] Policy Proposal 2004-3 point of order Folks: This may be more of a point of order, then a technical comment. This proposal has been positioned as a clarification not a change in policy. And I expect the result of the "vote" yesterday was primarily driven by that assertion. Let's ask a question and see how one might interpret policy under the old wording and new wording. Question: Will ARIN provide globally unique addresses to an entity that has no intention of advertising those addresses out to the Internet or making those addresses reachable from the Internet. Old wording: I suggest most folks would interpret the wording as "no". New wording: I suggest most would interpret the new wording as "yes". This sounds like a change in policy, not a clarification. I'm not sure the mandate from yesterday's vote is to change the policy. Joe Houle -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Dillon at radianz.com Tue Apr 19 10:25:50 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 19 Apr 2005 15:25:50 +0100 Subject: [ppml] Policy Proposal 2004-3 point of order In-Reply-To: Message-ID: > Question: Will ARIN provide globally unique addresses to an > entity that has no intention of advertising those addresses out to > the Internet or making those addresses reachable from the Internet. > Old wording: I suggest most folks would interpret the wording as ?no?. > New wording: I suggest most would interpret the new wording as ?yes?. > This sounds like a change in policy, not a clarification. RFC 2050 says the following in section 3 a): a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. Seems to me that if this were the wording of ARIN's policy then the answer to your question would be "yes". Since ARIN's policies are supposed to derive from RFC 2050, I really don't see how the clarification of wording could be interpreted as a change in policy. Here is the chronology that you claim: RFC 2050 - yes Old Wording - no New Wording - yes But there is no record of ARIN ever introducing a policy that went against RFC 2050 in this regard. Therefore, I believe that you are simply confused and are misinterpreting the policy based on the old wording. The new wording clears up this misunderstanding to restate the policy from RFC 2050 that has always been the operative policy. --Michael Dillon From marla_azinger at eli.net Tue Apr 19 10:32:51 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Tue, 19 Apr 2005 07:32:51 -0700 Subject: [ppml] Policy Proposal 2004-3 point of order Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20151216D@wava00s2ke2k01.corp.pvt> I cant beat this dead horse any more. Its not a change. Its a clarification. This is why we clarified. I can not help anyone who in the past may have interpreted it wrong. This is why we made the clarification. Moving forward -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Michael.Dillon at radianz.com Sent: Tuesday, April 19, 2005 7:26 AM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2004-3 point of order > Question: Will ARIN provide globally unique addresses to an > entity that has no intention of advertising those addresses out to > the Internet or making those addresses reachable from the Internet. > Old wording: I suggest most folks would interpret the wording as ?no?. > New wording: I suggest most would interpret the new wording as ?yes?. > This sounds like a change in policy, not a clarification. RFC 2050 says the following in section 3 a): a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. Seems to me that if this were the wording of ARIN's policy then the answer to your question would be "yes". Since ARIN's policies are supposed to derive from RFC 2050, I really don't see how the clarification of wording could be interpreted as a change in policy. Here is the chronology that you claim: RFC 2050 - yes Old Wording - no New Wording - yes But there is no record of ARIN ever introducing a policy that went against RFC 2050 in this regard. Therefore, I believe that you are simply confused and are misinterpreting the policy based on the old wording. The new wording clears up this misunderstanding to restate the policy from RFC 2050 that has always been the operative policy. --Michael Dillon From iggy at merit.edu Tue Apr 19 10:34:38 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Tue, 19 Apr 2005 10:34:38 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <42649F7A.88CC14AF@ix.netcom.com> References: <422F66F3.3090606@arin.net> <20050415192306.GB95722@ussenterprise.ufp.org> <2147483647.1113746839@imac-en0.delong.sj.ca.us> <42649F7A.88CC14AF@ix.netcom.com> Message-ID: In light of the legal points that made up the bulk of the objections to this policy proposal, my concerns about how and/or when you would allow ARIN to reclaim space based on some deffinition of 'non responsive'... It would seem my concerns are way overshadowed by the legal problems created by allowing some reassignment data to become private... However I want to make it clear that I still have objections to other parts of this proposal, perticularly section 3.2.1. My opinon remains that the only resaon for removal of data from the APID or SWIP is if it is proven to be fraudulent. Along the same lines the only grounds for any attempts to 'reclaim' ARIN resources based on data that's in this APID and/or SWIP, is if it should be proven to be fraudulent. So please do not attempt to push this policy though by just removing the refferances to private data... That is not the only problem with this proposal. Glenn Wiltse On Mon, 18 Apr 2005, Jeff Williams wrote: > Glenn and all, > > Good point. Yet this fictitious school you use as a very reasonable > example still should have valid and contactable contact information > avaliable/listed for their assigned Ipv4 resources. > > It is not reasonably conceivable that no contact can be made > for a period of longer than 15 days IMHO, unless there is a > death of the contact person in that period, or that person is > so ill as to be unable to respond. In even in both of these > special conditions, and alternative or backup contact person > should be available... > > Glenn Wiltse wrote: > > > Actualy I think there are ligitamate reasons that a POC may not be > > responsive for as many as 3 months. The policy proposal is unclear if this > > must be consecutive months or not, but this too is somewhat irrelevant. > > Consider a small special purpose school that may not operate for the whole > > summer. > > > > Glenn Wiltse > > > > On Sun, 17 Apr 2005, Owen DeLong wrote: > > > > Let me get back to a specific part of this policy proposal that I > > don't > > > > like... > > > > > > > > "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." I belive that there are > > > > > > > > I suggest to you that there can be valid re-assignments of ARIN > > > > resources, that may for a varitey of reasons become non-responsive for > > > > preiods of a month or longer, and should not constitute anything close to > > > > being grounds for reclaimation or maybe not even be grounds for > > > > 'suspension'(depending on how that is defined). Consider something such > > > > as a seasonal business, or a very small busines where possibly the entire > > > > staff is gone for a month or more. (possibly a small family based > > > > business, etc...) Well, you say ARIN staff can use there 'discretion' to > > > > determin that this is something that doesn't constitute a offense. I say > > > > that there shouldn't be room for ARIN staffs descretion... The only reason > > > > for reclaiming resources based on 'inaccurate' or 'non responsive' > > > > contacts, is FRAUD, which is legaly defined. > > > > > > > And it doesn't... It requires 4 times per month for three months. There's > > > no > > > legitimate reason for a valid POC for a network resource to be unreachable > > > for 3 months solid. A Seasonal business should have a responsive backup > > > POC from their upstream or such. Otherwise, the rest of the world is > > > expected to live with their resources being abused while they aren't > > > looking? > > > I think that is bad for the world. > > > > > > Owen > > > > > > -- > > > If it wasn't crypto-signed, it probably didn't come from me. > > > > > 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 > > > > !DSPAM:4264856a12311857916320! > > From bicknell at ufp.org Tue Apr 19 11:15:34 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 19 Apr 2005 11:15:34 -0400 Subject: [ppml] Policy Proposal 2004-3 point of order In-Reply-To: References: Message-ID: <20050419151534.GA56077@ussenterprise.ufp.org> In a message written on Tue, Apr 19, 2005 at 03:25:50PM +0100, Michael.Dillon at radianz.com wrote: > Here is the chronology that you claim: > > RFC 2050 - yes > Old Wording - no > New Wording - yes This is incorrect. ARIN has said "yes" under the old wording. The more accurate description is: RFC 2050 = yes, and everyone understood that it was a yes. Old Wording = yes, but some people were confused, and thought it was a no, like you. New Wording = yes, and everyone will understand it is a yes. -- 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 Michael.Dillon at radianz.com Tue Apr 19 11:37:57 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 19 Apr 2005 16:37:57 +0100 Subject: [ppml] Policy Proposal 2004-3 point of order In-Reply-To: <20050419151534.GA56077@ussenterprise.ufp.org> Message-ID: > In a message written on Tue, Apr 19, 2005 at 03:25:50PM +0100, > Michael.Dillon at radianz.com wrote: > > Here is the chronology that you claim: > > > > RFC 2050 - yes > > Old Wording - no > > New Wording - yes > > This is incorrect. ARIN has said "yes" under the old wording. The more > accurate description is: This is bizarre. You are the second person who is confused about what I am saying. > RFC 2050 = yes, and everyone understood that it was a yes. > Old Wording = yes, but some people were confused, and thought it was a > no, like you. I'm not confused. Read my words again, up above. I was merely restating the claim made by the first poster in order to show him where his confusion may have arisen. The chronology that I believe is as follows: RFC 2050 - yes Old wording - yes (poor phrasing, but no intentions to *CHANGE* RFC 2050.) New wording - yes (fixed the wording to make it clear that the policy is and always has been the same as RFC 2050) If anything, I suppose this demonstrates that we have to be careful how we state things. --Michael Dillon From jdhoule at att.com Tue Apr 19 14:08:13 2005 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Tue, 19 Apr 2005 13:08:13 -0500 Subject: [ppml] Policy Proposal 2004-3 point of order Message-ID: Michael et al: Thank you for the clarification. The advise you seem to be giving is that reading the policy manual and trying to interpret the actual policy based exclusively on those words is misguided. One must also read the applicable RFC(s) and make an interpretation across the history of applicable documents. Sorry for the distraction, but thanks for the history lesson. Joe Houle -----Original Message----- ... Here is the chronology that you claim: RFC 2050 - yes Old Wording - no New Wording - yes But there is no record of ARIN ever introducing a policy that went against RFC 2050 in this regard. Therefore, I believe that you are simply confused and are misinterpreting the policy based on the old wording. The new wording clears up this misunderstanding to restate the policy from RFC 2050 that has always been the operative policy. --Michael Dillon From steven.feldman at cnet.com Tue Apr 19 16:33:34 2005 From: steven.feldman at cnet.com (Steve Feldman) Date: Tue, 19 Apr 2005 16:33:34 -0400 Subject: [ppml] 2005-1 alternatives In-Reply-To: References: Message-ID: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> So there wasn't overwhelming support this morning for 2005-01. Why did people vote against it? Because the proposed criteria for allowing PI assignment were bad, because PI space is a bad idea in general, or something else? If it's the criteria, what would work better? Maybe possession of PI v4 space? That _and_ an AS number? Steve From dr at cluenet.de Tue Apr 19 17:01:33 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 19 Apr 2005 23:01:33 +0200 Subject: [ppml] 2005-1 alternatives In-Reply-To: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> Message-ID: <20050419210133.GA18462@srv01.cluenet.de> On Tue, Apr 19, 2005 at 04:33:34PM -0400, Steve Feldman wrote: > So there wasn't overwhelming support this morning for 2005-01. > Why did people vote against it? If the webcast would have worked for me (local problem here it seems, as all others seemed to have no probs in joining the stream) I would have asked the voters about how many are representing ISPs, how many vendors and how many organizations which would benefit of PI. That would have been an interesting number. What were the actual voting results? > Maybe possession of PI v4 space? Why that? What sense would that make? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Ed.Lewis at neustar.biz Tue Apr 19 17:11:42 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 19 Apr 2005 17:11:42 -0400 Subject: [ppml] 2005-1 alternatives In-Reply-To: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> Message-ID: At 16:33 -0400 4/19/05, Steve Feldman wrote: >So there wasn't overwhelming support this morning for 2005-01. >Why did people vote against it? Because the proposed criteria >for allowing PI assignment were bad, because PI space is a bad >idea in general, or something else? I'm going to take a stab at answering this, bearing in mind I probably voted for it (can't remember), have never worked for an ISP and have never been the person that had to deal with a provider. So - the issues I will describe are perceived rather than from experience. There are two reasons why I would want to control my IP address range. One is that I don't trust that a single ISP can provide the service I want. - I fear that if my ISP goes out of business overnight, I'm stuck - I want to have more control over my resiliency + Accomplishing this means multihoming and advertising my space two+ ways The other is that I fear that renumbering would inflict a heavy cost to me. - I have lots of manually configured security devices, firewall rules - I don't like leaving server addresses to chance, relying on dynamic DNS + Automatic configuration isn't automatic enough My early impression of IPv6 was that it would usher in a new era in which network layer details, like addresses and routing, would be left to ISPs as the layer 3 entities. Network topology would rule the day, making the routing tables more efficient. Addressing would be painless, being able to only need to tweak the routers to change prefixes. In DNS, binary labels and A6 records would rule. As time has progressed though, the promise seems to have slipped away. Security devices, featuring ACLs, have made the network brittle. No longer is a server's address just for the server, the router, and DNS to know - the firewall too. (And I'd think twice about automatic updates to security devices.) From an operations point of view, I need obvious determinism - like being able to look at a packet dump and know "oh, that's the address of the ftp server." The work in the IETF's multi6 (and the following shim6) will be important to the success of multihoming in IPv6. It would be good (I haven't followed closely) if multihoming could mean that I get prefixes from each provider simultaneously. IMHO, if enterprises could trust the ISPs - and I mean has a whole, not individually - I doubt that there'd be a rationalization for "provider independent" uniquely globally routable address space. Such space would not be efficient. So there's a latent desire for provider independent space. But, the impact of having it is that we take away from the routing community the ability to optimize the route tables. We also remove the impetus to demand security products that are address-flexible. From a system-wide point of view, I don't like provider-independent space. But I can't deny the utility of it to an enterprise that puts a huge stake into networking as internal infrastructure. (I've tried to keep this short, so I've dropped some details.) I'm curious to hear opinions too. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From kloch at hotnic.net Tue Apr 19 17:23:24 2005 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 19 Apr 2005 17:23:24 -0400 Subject: [ppml] 2005-1 alternatives In-Reply-To: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> Message-ID: <426576CC.9000208@hotnic.net> Steve Feldman wrote: > So there wasn't overwhelming support this morning for 2005-01. > Why did people vote against it? Because the proposed criteria > for allowing PI assignment were bad, because PI space is a bad > idea in general, or something else? I'm sorry to hear that. I had a schedule conflict otherwise I would have been there to support it. > > If it's the criteria, what would work better? > Maybe possession of PI v4 space? That _and_ an AS number? IMO, IPv4 addresses should never be used as a prerequisite for IPv6 allocations. 2005-1 allocations are intended for those who will be multihoming in IPv6. Demonstrating likely IPv6 (not IPv4) multihoming would be the ideal prerequisite. The ASN requirement comes close to this, though it would include many IPv4 only multihomers. In the interest of encouraging deployment, I think this superset is good in the near term. - Kevin From steven.feldman at cnet.com Tue Apr 19 17:36:03 2005 From: steven.feldman at cnet.com (Steve Feldman) Date: Tue, 19 Apr 2005 17:36:03 -0400 Subject: [ppml] 2005-1 alternatives In-Reply-To: <20050419210133.GA18462@srv01.cluenet.de> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> <20050419210133.GA18462@srv01.cluenet.de> Message-ID: <67119f45eefb3952902c9cbebe7dbfb5@cnet.com> >> Maybe possession of PI v4 space? > > Why that? What sense would that make? It's just a strawman, but I was trying to think of some objective criterion that said the applicant is a legitimate multihomer, not just an address space squatter. Better ideas are encouraged! The main objection to using possession of an AS as the criterion was that it would cause a run on the RIRs for new AS assignments. Steve From owen at delong.com Tue Apr 19 17:39:36 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Apr 2005 14:39:36 -0700 Subject: [ppml] Policy Proposal 2004-3 point of order In-Reply-To: References: Message-ID: <2147483647.1113921576@imac-en0.delong.sj.ca.us> The fact that most folks would interpret it as "no" while, in fact, the policy has always been "yes" under certain circumstances, is exactly why the authors felt that the clarification was needed. It is a clarification, not a change in policy, and, you have just proven why said clarification was needed. Owen --On Tuesday, April 19, 2005 8:54 AM -0500 "Houle, Joseph D (Joe), CMO" wrote: > > > Folks: > > This may be more of a point of order, then a technical comment. > This proposal has been positioned as a clarification not a change in > policy. And I expect the result of the "vote" yesterday was primarily > driven by that assertion. > > Let's ask a question and see how one might interpret policy under the > old wording and new wording. > > Question: Will ARIN provide globally unique addresses to an entity > that has no intention of advertising those addresses out to the Internet > or making those addresses reachable from the Internet. > > Old wording: I suggest most folks would interpret the wording as > "no". > > New wording: I suggest most would interpret the new wording as > "yes". > > This sounds like a change in policy, not a clarification. > > I'm not sure the mandate from yesterday's vote is to change the > policy. > > Joe Houle > > -- 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 gih at apnic.net Tue Apr 19 19:03:28 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 20 Apr 2005 09:03:28 +1000 Subject: [ppml] 2005-1 alternatives In-Reply-To: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> Message-ID: <6.0.1.1.2.20050420085434.038f77f0@localhost> At 06:33 AM 20/04/2005, Steve Feldman wrote: >So there wasn't overwhelming support this morning for 2005-01. >Why did people vote against it? Because the proposed criteria >for allowing PI assignment were bad, because PI space is a bad >idea in general, or something else? > >If it's the criteria, what would work better? >Maybe possession of PI v4 space? That _and_ an AS number? I suspect that the underlying issue is that we've managed to surprise ourselves a couple of times when the routing table has made a few leaps upward at a rate that looked like it would overwhelm the capability of the deployed routing infrastructure, and the reaction has been one of viewing impacts on routing in a conservative manner by those who got worried at the time. In some ways scaling routing is not exactly a well understood topic, and there is some doubting of the wisdom of the optimistic view of "well we'll solve that routing explosion problem when it 's clearly obvious that its about to go bang!". If we understood routing scaling and the dynamics of routing at both a technology and at a business level maybe we'd have a more coherent common view of what is good housekeeping of routing and the associated topic of what is good housekeeping of address blocks that make their way into routing. As it stands what I saw today is best expressed as an unclear picture of where the best long term interests lie here for the network itself. But then the duality and implicit tensions of routing scaleability and addresses utility goes back a very long way - the Routing and Addressing Group of the IETF in the early 1990s was an early incarnation of the same set of tensions relating to what makes routing scale vs what makes addresses truly useful and convenient to use. regards, Geoff From dr at cluenet.de Tue Apr 19 19:17:28 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 20 Apr 2005 01:17:28 +0200 Subject: [ppml] 2005-1 alternatives In-Reply-To: <67119f45eefb3952902c9cbebe7dbfb5@cnet.com> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> <20050419210133.GA18462@srv01.cluenet.de> <67119f45eefb3952902c9cbebe7dbfb5@cnet.com> Message-ID: <20050419231728.GA19678@srv01.cluenet.de> On Tue, Apr 19, 2005 at 05:36:03PM -0400, Steve Feldman wrote: > >>Maybe possession of PI v4 space? > > > >Why that? What sense would that make? > > It's just a strawman, but I was trying to think of some objective > criterion that said the applicant is a legitimate multihomer, not > just an address space squatter. Better ideas are encouraged! I'm not sure about ARIN policy here, but in RIPE, only multihomers do get an ASN nowadays. > The main objection to using possession of an AS as the criterion > was that it would cause a run on the RIRs for new AS assignments. Depends on what the policy for getting an ASN is. If it needs multihoming, then... well... I don't think people will start multihoming just to get IPv6 PI space in a landrush... Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From randy at psg.com Wed Apr 20 02:41:06 2005 From: randy at psg.com (Randy Bush) Date: Tue, 19 Apr 2005 20:41:06 -1000 Subject: [ppml] 2005-1 alternatives References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> <6.0.1.1.2.20050420085434.038f77f0@localhost> Message-ID: <16997.63874.469259.203133@roam.psg.com> > and there is some doubting of the wisdom of the optimistic view of "well > we'll solve that routing explosion problem when it 's clearly obvious that > its about to go bang!". some of us remember how much work it took to fix this the last time, and the damage to customers in the process. i do not think the current use of the internet by society would tolerate a mess of the scale we had in the early '90s, with entire international isps down for days, etc. randy From owen at delong.com Wed Apr 20 03:26:11 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2005 00:26:11 -0700 Subject: [ppml] 2005-1 alternatives In-Reply-To: <6.0.1.1.2.20050420085434.038f77f0@localhost> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> <6.0.1.1.2.20050420085434.038f77f0@localhost> Message-ID: <2147483647.1113956771@[172.17.1.152]> > But then the duality and implicit tensions of routing scaleability and > addresses utility goes back a very long way - the Routing and Addressing > Group of the IETF in the early 1990s was an early incarnation of the same > set of tensions relating to what makes routing scale vs what makes > addresses truly useful and convenient to use. > That is why I am becoming progressively more convinced that we need to separate these two functions. Addressing primarily provides an end-system identifier function. Unfortunately, because we have chosen to also use a portion of this Address to provide routing information as well, we have painted ourselves into a corner on these issues, repeatedly. I think it is time to take a step back and consider a more radical approach to separating these two functions. In the long run, I think we would do well to consider the possibility of eliminating prefixes from interdomain routing, and, instead, build a facility for looking up the origin-AS for a given prefix, and, routing strictly on origin-AS. WIthin a given AS, routing would occur as it does now, but, Interdomain routing is where we face table overflow, not intr-as routing. The bottom line is that IPv6 doesn't provide any benefits over IPv4 to most adopters today. IPv4 has provisions for getting PI space, and, people are using them because there are lots of things that just don't work right or sufficiently without it. IPv6 has not solved ANY of these problems. There are, as I see it, two solutions on the horizon for this situation in IPv6. The first is ULA, which, has most of the drawbacks of RFC-1918 address space, but, lacks the self-enforcing limits of RFC-1918 IPv4 address space. The reality is that absent a forcing function to keep ULA from getting routed globally (such as the inherent overlap issues with RFC-1918 space), market demands will become a forcing function driving more and more ISPs to route more and more ULA space. Absent this policy, or, one like it, there are three possible outcomes: 1. IPv6 adoption will continue to be delayed until such time as IPv4 space is virtually exhausted and there is no further possibility to limp along with IPv4. 2. IPv6 adopters will drive the global routing of ULA over time. 3. Most IPv6 adopters will find or fabricate a way to act as an LIR out of desperation to obtain PI space under existing policy. 4. All of the people who have very legitimate and well thought out needs for PI address space will simply fade into the woodwork and accept IPv6 as is with PA space and renumber whenever they have to. Of the 4, I can see any or some combination of all of the first 3 as being likely. I think that the fourth is what the current IETF proposals are banking on, and, I think that any real-world perspective will clearly show that there is absolutely no historical precedent or reason to believe that it is at all likely. 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 jwkckid1 at ix.netcom.com Wed Apr 20 06:29:58 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 20 Apr 2005 03:29:58 -0700 Subject: [ppml] 2005-1 alternatives References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> <6.0.1.1.2.20050420085434.038f77f0@localhost> <2147483647.1113956771@[172.17.1.152]> Message-ID: <42662F23.A7479931@ix.netcom.com> Owen and all, By golly I agree with just about everything you said below. I would add a couple of caveats. 1.) It is likely and in process/progress that Ipv6 will be supplanted by more advanced and more secure Ip protocols... 2.) Concerns regarding privacy and security are becoming more and more broad reaching. With Ipv6's shortcomings in this area, and Ipsec still a mess, there is a good chance that Ipv6 may loose any attractiveness it could have now... Owen DeLong wrote: > > But then the duality and implicit tensions of routing scaleability and > > addresses utility goes back a very long way - the Routing and Addressing > > Group of the IETF in the early 1990s was an early incarnation of the same > > set of tensions relating to what makes routing scale vs what makes > > addresses truly useful and convenient to use. > > > > That is why I am becoming progressively more convinced that we need > to separate these two functions. Addressing primarily provides an > end-system identifier function. Unfortunately, because we have chosen > to also use a portion of this Address to provide routing information as > well, we have painted ourselves into a corner on these issues, repeatedly. > > I think it is time to take a step back and consider a more radical approach > to separating these two functions. In the long run, I think we would do > well to consider the possibility of eliminating prefixes from interdomain > routing, and, instead, build a facility for looking up the origin-AS for > a given prefix, and, routing strictly on origin-AS. WIthin a given AS, > routing would occur as it does now, but, Interdomain routing is where > we face table overflow, not intr-as routing. > > The bottom line is that IPv6 doesn't provide any benefits over IPv4 to > most adopters today. IPv4 has provisions for getting PI space, and, > people are using them because there are lots of things that just don't > work right or sufficiently without it. IPv6 has not solved ANY of these > problems. > > There are, as I see it, two solutions on the horizon for this situation in > IPv6. The first is ULA, which, has most of the drawbacks of RFC-1918 > address space, but, lacks the self-enforcing limits of RFC-1918 IPv4 > address space. The reality is that absent a forcing function to keep > ULA from getting routed globally (such as the inherent overlap issues > with RFC-1918 space), market demands will become a forcing function > driving more and more ISPs to route more and more ULA space. Absent > this policy, or, one like it, there are three possible outcomes: > > 1. IPv6 adoption will continue to be delayed until such > time as IPv4 space is virtually exhausted and there is > no further possibility to limp along with IPv4. > > 2. IPv6 adopters will drive the global routing of ULA > over time. > > 3. Most IPv6 adopters will find or fabricate a way to > act as an LIR out of desperation to obtain PI space > under existing policy. > > 4. All of the people who have very legitimate and well thought > out needs for PI address space will simply fade into the > woodwork and accept IPv6 as is with PA space and renumber > whenever they have to. > > Of the 4, I can see any or some combination of all of the first 3 as being > likely. I think that the fourth is what the current IETF proposals are > banking on, and, I think that any real-world perspective will clearly > show that there is absolutely no historical precedent or reason to believe > that it is at all likely. > > Owen > > -- > If this message was not signed with gpg key 0FE2AA3D, it's probably > a forgery. > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit 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 gih at apnic.net Wed Apr 20 08:22:17 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 20 Apr 2005 22:22:17 +1000 Subject: [ppml] 2005-1 alternatives In-Reply-To: <2147483647.1113956771@[172.17.1.152]> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> <6.0.1.1.2.20050420085434.038f77f0@localhost> <2147483647.1113956771@[172.17.1.152]> Message-ID: <6.0.1.1.2.20050420220734.02410e00@localhost> At 05:26 PM 20/04/2005, Owen DeLong wrote: >>But then the duality and implicit tensions of routing scaleability and >>addresses utility goes back a very long way - the Routing and Addressing >>Group of the IETF in the early 1990s was an early incarnation of the same >>set of tensions relating to what makes routing scale vs what makes >>addresses truly useful and convenient to use. > >That is why I am becoming progressively more convinced that we need >to separate these two functions. Welcome to a well established area of consideration! There is a rich body of material that has been generated over as many years as we've been thinking about packet networking. There are papers dating back to the early 60's on this issue of what is currently referred to as the id/loc split, and the topic space encompasses various forms of routing paradigms, end host paradigms and their various forms of interaction. In one sense its a wonderfully unconstrained place to think in in the abstract, and it would be wonderful to see many more folk should be thinking and working in this area than we have today. But in practical terms there are a myriad of constraints that needs to be considered when you come down to the harshness of reality. Personally I'm of the opinion that its safest, when considering what risks we want to run, to assume that routing capability and functionality will pretty much continue for some time yet to be what we see today, and also, for some time yet addresses will continue to have the semantic overload of entity identification and location identification. It's this rather conservative view of the world as we know it that is a valid consideration when looking at these kind of policy proposals, and yes, there is an amazing level of tension between maximizing the utility and stability of addresses, and maximizing the prospects of routing to continue to pass these address tokens around the network. regard, Geoff From memsvcs at arin.net Wed Apr 20 09:07:44 2005 From: memsvcs at arin.net (Member Services) Date: Wed, 20 Apr 2005 09:07:44 -0400 Subject: [ppml] Global Policy: IANA Allocation of IPv4 Address Space to the RIRs Message-ID: <20050420130747.D3E241FE8D@mercury.arin.net> On April 8 2005, the ICANN Board formally approved the adoption of a global policy on IANA Allocation of IPv4 address space to the Regional Internet Registries developed by the Address Supporting Organization (ASO) and the Number Resource Organization (NRO). This policy was ratified in the ARIN region on December 22, 2003. The Global Addressing Policy document is available from the ASO website at: http://aso.icann.org/docs/aso-001-2.pdf The policy text is found as section 10.1 in the ARIN Number Resource Policy Manual at: http://www.arin.net/policy/index.html#ten Regards, Member Services American Registry for Internet Numbers (ARIN) From bicrawf at yahoo.com Wed Apr 20 10:48:21 2005 From: bicrawf at yahoo.com (Benjamin Crawford) Date: Wed, 20 Apr 2005 07:48:21 -0700 (PDT) Subject: [ppml] 2005-1:Business Need for PI Assignments Message-ID: <20050420144822.36523.qmail@web52006.mail.yahoo.com> It is extremely important to realize that organizations, with responsibilities to their customers and shareholders, will not be willing to move forward with IPv6 if their v6 allocations will be tied in to a specific service provider. This point was made by several representatives at the PPM in Orlando and needs to be given strong consideration. IPv6 acceptance will continue to be prolonged until a time that a policy or technology is put in to place that will not bind an organization to a service provider due to an IPv6 allocation. At this time, the policy should be supported to help get v6 off of the shelf and accepted by many of the businesses out there who are starting to look at this new protocol. -Ben Crawford __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From randy at psg.com Wed Apr 20 11:32:07 2005 From: randy at psg.com (Randy Bush) Date: Wed, 20 Apr 2005 05:32:07 -1000 Subject: [ppml] 2005-1:Business Need for PI Assignments References: <20050420144822.36523.qmail@web52006.mail.yahoo.com> Message-ID: <16998.30199.508204.447952@roam.psg.com> > It is extremely important to realize that organizations, with > responsibilities to their customers and shareholders, will not be > willing to move forward with IPv6 if their v6 allocations will be > tied in to a specific service provider. but our ipv6 promotion and marketing are not in the major goals of the RIRs. stewardship is. sometimes there may be a tension between the two. welcome to real life. randy From david.conrad at nominum.com Wed Apr 20 11:47:17 2005 From: david.conrad at nominum.com (David Conrad) Date: Wed, 20 Apr 2005 08:47:17 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <20050420144822.36523.qmail@web52006.mail.yahoo.com> References: <20050420144822.36523.qmail@web52006.mail.yahoo.com> Message-ID: Ben, While I understand the position you put forward, if addresses are not obtained from providers, then the address prefix will need to appear in all default-free routers through which connectivity is desired. It is, of course, true that at this point in time there is plenty of space in the "global routing tables", the question is, will that last for the lifetime of IPv6? Many people feel it would be wise to learn from previous mistakes. Rgds, -drc On Apr 20, 2005, at 7:48 AM, Benjamin Crawford wrote: > It is extremely important to realize that > organizations, with responsibilities to their > customers and shareholders, will not be willing to > move forward with IPv6 if their v6 allocations will be > tied in to a specific service provider. This point > was made by several representatives at the PPM in > Orlando and needs to be given strong consideration. > IPv6 acceptance will continue to be prolonged until a > time that a policy or technology is put in to place > that will not bind an organization to a service > provider due to an IPv6 allocation. At this time, the > policy should be supported to help get v6 off of the > shelf and accepted by many of the businesses out there > who are starting to look at this new protocol. -Ben Crawford > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From Ed.Lewis at neustar.biz Wed Apr 20 12:04:53 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 20 Apr 2005 12:04:53 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <16998.30199.508204.447952@roam.psg.com> References: <20050420144822.36523.qmail@web52006.mail.yahoo.com> <16998.30199.508204.447952@roam.psg.com> Message-ID: At 5:32 -1000 4/20/05, Randy Bush wrote: >> It is extremely important to realize that organizations, with >> responsibilities to their customers and shareholders, will not be >> willing to move forward with IPv6 if their v6 allocations will be >> tied in to a specific service provider. > >but our ipv6 promotion and marketing are not in the major goals >of the RIRs. stewardship is. sometimes there may be a tension >between the two. welcome to real life. I'm missing something here. This is what I am either assuming or think I am hearing: 1) The RIRs require that ISPs be prepared to sign up 200 customers in 5 years in order to get space (via the policy). Only ISPs can get space. 2) Customers are having trouble with a technology that requires putting faith into ISPs, an industry that has proven quite economically unstable in recent years. 1+2 seems to imply that supply and demand will have a hard time materializing. How does IPv6 gain momentum when adopters at the edge of the network (customers) can't get space without having to rely on (and pay money to) a core infrastructure that has a poor (recent) track record for business stability? (Thinking of a recent discussion of SSH vs. DNSSEC in another forum - innovation at the edge vs innovation at the core and adoption rates.) I understand that from an engineering perspective, IPv6 addressing ought to be handled by the ISP (the layer 3 service provider) (- that sounds very POTS-like). But this seems hard to achieve when business is considered. Engineering vs. Economics. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From william at elan.net Wed Apr 20 13:10:30 2005 From: william at elan.net (william(at)elan.net) Date: Wed, 20 Apr 2005 10:10:30 -0700 (PDT) Subject: [ppml] Comments sent to open michrophone Message-ID: Per request I'm reposting text of comment to the list. ------------------------------------ These are comments for open microphone session at ARIN members meeting on Wednesday (which as has been mentioned can be continuation of open microphone at public policy meeting on Tuesday). During brief comments on Tuesday the issues raised were in regards to problem with bogon filters by somebody from Shaw and separately regarding problems with blocklists and possible relation of that to bogons by person from SBC. I'd like to address some of the concerns raised and provide clarification of the problems, some of which are specific to the companies mentioned. Before I begin I would like to first apologize for the length of my text as there are number of separate issues here that have to be explained. First of all regarding bogons it is certainly true, that those who get allocations from new /8 blocks experience some problems with connectivity. This is largely due static bogon filters that some ISPs use and it did not help that cisco was for some time selling routers that came with security auto-configuration feature with static filter of unassigned IANA /8 blocks that were known at the time router was made. These routers do not have auto update feature for this filter and unfortunately majority of them are used at the isp-edge by smaller companies that do not have IT department dedicated to internet engineering that could regularly update bogon filter. The situation is now better as IANA unallocated filter has been removed from default security configuration of the newly sold cisco routers and those that have old static filter as well as ISPs that similarly use static bogon filter are being identified by efforts such as the one ARIN is going to participate when testing connectivity of its new 73/8 block. If other ISPs here would like to help, I would encourage to check with your T1 and similar customers and especially ask if they had either setup bogon filter on their own or used autosecure command on cisco router bought within last 18 months and if so help make sure that bogon filter is removed or kept updated. Another bogon related issue for ISPs is making sure that the ip block being announced in BGP correctly matches size of ip block allocation listed in ARIN whois. If its not then those users on the part of ip block that has no whois allocation data may see themselves blocked by bogon filter. As an example currently Shaw Communications is announcing in BGP network 70.64.0.0/13, where as corresponding ip block in in ARIN whois is 70.64.0.0 to 70.71.111.255, which means almost 1/2 of the announced block is bogon. This also causes entire block announced in bgp to appear as active bogon in some monitoring systems such as ones run by completewhois.com or seen in weekly cidr-report. I'm sure in this case as in many others this was not intentional and simply an oversight or miscommunication to network engineering team as to the expect size of arin allocation and improved internal company communication and double-checking would help to avoid problems like this. Moving on to the comments made by the gentlemen from SBC who noted that individual ips are sometimes reported as being blocked by bogon filter. It should certainly be noted that number of users who are doing bogon filtering on individual computers or with specific service such as mail has increased 100 times or more in the last 12 months (at least based on logs at completewhois dns-based bogon service and that does not account for all those who download entire bogon list on regular basis with ftp, rsync or http), but all such bogon data is kept accurate and updated daily and there were no serious errors with the data in at least a year, so except for few cases such as one mentioned with Shaw, the users should not see their individual ips blocked by bogon filter. Instead what is happening is that many end-users who use bogon filtering may also be using number of other blocklists, especially for mail filtering. Some users would then get confused as to exactly which of the blocklists was responsible for inability to communicate and may blame bogon filter when it is almost certain is not the problem. This maybe result of either human error or technical problem, for example openrbl.org which some use to determine if ip is on any blocklist (and if so which one) has a problem with their algorithm as they use string comparison instead of numerical and this results in errors in about 5% of what they report as a match. For this and similar reasons any reports of ip being on any blocklist should always be double-checked by ISP staff by using dig or similar utility to document and verify exactly which blocklist is a problem. Further I remember that gentlemen from SBC mentioned that they ran into problems with delisting of the ips from some blocklists and he complained that somebody was asking them $2000 for it. I find this highly unlikely and while I don't pretend have list of every blocklist every used or know all their policies, all the major ones I'm aware of do not operate in this way and are maintained based on donations or support of those who use blocklist. None of those I know ever ask for money for delisting with exception of SORBS (and I dont support their policy in this regard) that does ask for $50 (but not $2000!) to be donated to a charity and that is only to get the case expedited as otherwise listings there would still be removed, it may just take longer. So the issue is not likely to be money if ISP block or ip is listed, but time it may take for ISP techs to get in touch with blocklist operator and answer their questions (usually to make certain the reported abuse has been dealt with). Next it was also noted by gentelement representing SBC that while abuse only came from one or two specific ips (often due to viruses or user computer becoming a zombie controlled by spammer) larger ISP blocks are ending up in blocklist. Again I don't pretend to know policy of every blocklist, but I do know that many if not majority do lookups in ARIN whois to try to determine size of the block to be listed. And while some blocklist would only limit to individual ips, its often enough that abuse comes from several nearby ips and usually the problem are several computers on the same LAN (easier for virus to spread and if more then one computer is vulnerable its likely that same organization may have security problem and other computers that are vulunerable too) and as such preventative measure has been to expand listing to entire ip block as listed in end-user assignment. In case of SBC, this may have caused some additional problems. In particular for last 12 months SBC has been listing in whois large blocks (such as /22) as "Residential Customer / Private Address". While I originally thought myself this assignment is to just one customer (as per my reading of 2003-3 policy), after further research, I came to believe that majority of such /22 are combined listing for many individual residential dsl customers with actual user assignments varying from /32 to /26 and that SBC is choosing to consolidate it all into one reassignment. Blocklist operators may also be confused by this and believe that it really is one reassignment and not multiple SBC customers. As my interpretation of 2003-3 is different then the use by SBC described above, I would like to see ARIN staff provide their position as to if consolidation of multiple reassignment records into one very large one and listing it all as "Private Customer" is in accordince with the policy. In either case it does seem that this use is causing misunderstanding as to the size of the exact block assigned by SBC to a customer and this may well be part of the reason for larger SBC blocks getting listed. I hope in above remarks I clarifed some of the issues in regards to bogons and blocklisting. If you do have more comments on these subjects, please raise them further on ppml or other appopriate mail list. -- William Leibzon Elan Networks william at elan.net From lea.roberts at stanford.edu Wed Apr 20 14:20:30 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Wed, 20 Apr 2005 11:20:30 -0700 (PDT) Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <20050420144822.36523.qmail@web52006.mail.yahoo.com> Message-ID: Ben - thanks for your comments and for your presence at our meeting. I think many of us in the community heard your message loud and clear. I hope you have subscribed to PPML and will continue to participate in the evolution of 2005-1. /Lea On Wed, 20 Apr 2005, Benjamin Crawford wrote: > It is extremely important to realize that > organizations, with responsibilities to their > customers and shareholders, will not be willing to > move forward with IPv6 if their v6 allocations will be > tied in to a specific service provider. This point > was made by several representatives at the PPM in > Orlando and needs to be given strong consideration. > IPv6 acceptance will continue to be prolonged until a > time that a policy or technology is put in to place > that will not bind an organization to a service > provider due to an IPv6 allocation. At this time, the > policy should be supported to help get v6 off of the > shelf and accepted by many of the businesses out there > who are starting to look at this new protocol. -Ben Crawford > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From lea.roberts at stanford.edu Wed Apr 20 15:06:38 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Wed, 20 Apr 2005 12:06:38 -0700 (PDT) Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: Message-ID: David, Randy (et al) -0- I too would like to continue to live the original fantasy of IPv6 where one could renumber at will and multihome by connecting to as many providers as you were willing to pay. However, looking at the current "operational experience" of which I am aware, neither of those deliverables has yet become real. Are you aware otherwise? I do understand that there may come a day when the DFZ will only be able to contain the maximum aggregation prefixes, but hopefully before then some real multihoming option will exist. Until then, the IPv4 equivalent technique, announcing the more specific prefix, will likely continue, so whether it is PI or PA, it's still a RIB slot. (yeah, I know the more specifics can be filtered at a distance for PA but not PI. It's still a long time from that state for IPv6) Sticking with the "no PI space" mantra for IPv6 in the absence of viable multihoming and/or easy renumbering is just plain wrong. We need to come up with a criteria for PI space that will constrain the recipient pool to a reasonably small set of large institutions, i.e. those who will be multi-homing and for whom renumbering would be a major and painful task. I invite all PPML readers to help us to reach that goal... thanks in advance, /Lea On Wed, 20 Apr 2005, David Conrad wrote: > Ben, > > While I understand the position you put forward, if addresses are not > obtained from providers, then the address prefix will need to appear in > all default-free routers through which connectivity is desired. It is, > of course, true that at this point in time there is plenty of space in > the "global routing tables", the question is, will that last for the > lifetime of IPv6? > > Many people feel it would be wise to learn from previous mistakes. > > Rgds, > -drc > > On Apr 20, 2005, at 7:48 AM, Benjamin Crawford wrote: > > > It is extremely important to realize that > > organizations, with responsibilities to their > > customers and shareholders, will not be willing to > > move forward with IPv6 if their v6 allocations will be > > tied in to a specific service provider. This point > > was made by several representatives at the PPM in > > Orlando and needs to be given strong consideration. > > IPv6 acceptance will continue to be prolonged until a > > time that a policy or technology is put in to place > > that will not bind an organization to a service > > provider due to an IPv6 allocation. At this time, the > > policy should be supported to help get v6 off of the > > shelf and accepted by many of the businesses out there > > who are starting to look at this new protocol. -Ben Crawford > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > From william at elan.net Wed Apr 20 15:29:01 2005 From: william at elan.net (william(at)elan.net) Date: Wed, 20 Apr 2005 12:29:01 -0700 (PDT) Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: On Wed, 20 Apr 2005, Lea Roberts wrote: > David, Randy (et al) -0- > > I too would like to continue to live the original fantasy of IPv6 where > one could renumber at will and multihome by connecting to as many > providers as you were willing to pay. However, looking at the current > "operational experience" of which I am aware, neither of those > deliverables has yet become real. Are you aware otherwise? > > I do understand that there may come a day when the DFZ will only be able > to contain the maximum aggregation prefixes, but hopefully before then > some real multihoming option will exist. Until then, the IPv4 equivalent > technique, announcing the more specific prefix, will likely continue, so > whether it is PI or PA, it's still a RIB slot. (yeah, I know the more > specifics can be filtered at a distance for PA but not PI. It's still a > long time from that state for IPv6) > > Sticking with the "no PI space" mantra for IPv6 in the absence of viable > multihoming and/or easy renumbering is just plain wrong. We need to come > up with a criteria for PI space that will constrain the recipient pool to > a reasonably small set of large institutions, i.e. those who will be > multi-homing and for whom renumbering would be a major and painful task. I did not comment before on the issue before I was also trying to decide if evil of new swamp space is worth necessary to multi-home right away. However I do have to agree with Lea others now and think that policy for ipv6 micro-allocations for multihomed customers should exist. Additionally I'd like to note that by not having this policy we may well be delaying deployment of IPv6 in US and Canada and so North America may well be getting further and further behind (and we're alredy behind both Europe and Asia), I really dont think this is good and it may well get to the point that it begins to effect economy either directly or indirectly (as new research and new inventions on internet would shift to where internet technologies are more advanced). -- William Leibzon Elan Networks william at elan.net From RLindsey at coinfotech.com Wed Apr 20 15:43:50 2005 From: RLindsey at coinfotech.com (Randy Lindsey) Date: Wed, 20 Apr 2005 13:43:50 -0600 Subject: [ppml] 2005-1:Business Need for PI Assignments Message-ID: <8D528F7C177242458A7AB5C5C13B675F1CC232@oak.cit.office> > We need to come up with a criteria for PI space that will constrain > the recipient pool to a reasonably small set of large institutions, > i.e. those who will be multi-homing and for whom renumbering would be > a major and painful task. Not only large institutions find it painful and expensive to renumber. Small ISP's take just as long, and relative to their size the expense is as great or greater than for a large one. Remember staff resources are proportional to size of the organization. Years ago it took my small ISP months to migrate from one provider's /21 to another provider. The current IPv4 minimum of a /19 or /20 is already tough for small ISP's to reach and eliminates nearly all end-user organizations (in the larger context of millions of end-user organizations). I think the IPv6 limit should target the same size of organization as the current IPv4 limit does. If I multi-home and can qualify for a PI block under IPv4, I should be able to get one in IPv6 too. Randy Lindsey Colorado Information Technologies, Inc. http://www.coinfotech.com From Ed.Lewis at neustar.biz Wed Apr 20 15:51:50 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 20 Apr 2005 15:51:50 -0400 Subject: [ppml] ARIN Certificates Message-ID: In the members meeting, it was reported that cases of attempted registration fraud have been observed. (Details I don't have...) I asked about uptake on ARIN's certificate service (http://www.arin.net/CA) and heard that the community hasn't been taking advantage of this. Consider this a request for folks with ARIN POC's to look into this service... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From gih at apnic.net Wed Apr 20 16:33:40 2005 From: gih at apnic.net (Geoff Huston) Date: Thu, 21 Apr 2005 06:33:40 +1000 Subject: [ppml] ARIN Certificates In-Reply-To: References: Message-ID: <6.0.1.1.2.20050421063020.03cded80@localhost> At 05:51 AM 21/04/2005, Edward Lewis wrote: >In the members meeting, it was reported that cases of attempted >registration fraud have been observed. (Details I don't have...) I asked >about uptake on ARIN's certificate service (http://www.arin.net/CA) and >heard that the community hasn't been taking advantage of this. > >Consider this a request for folks with ARIN POC's to look into this service... In APNIC the update rate for cert-based access has been significantly higher. Perhaps the reasons for this are based on the observation that a password-based alternative access mechanism is not a highly secure mechanism, and also that cert-based access is the only supported access method. regards Geoff Huston From david.conrad at nominum.com Wed Apr 20 16:39:38 2005 From: david.conrad at nominum.com (David Conrad) Date: Wed, 20 Apr 2005 13:39:38 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: <83981c6d44918a10e779dc2781f24f27@nominum.com> Lea, On Apr 20, 2005, at 12:06 PM, Lea Roberts wrote: > David, Randy (et al) -0- This demonstrates my interest in multihoming... :-) > I too would like to continue to live the original fantasy of IPv6 where > one could renumber at will and multihome by connecting to as many > providers as you were willing to pay. However, looking at the current > "operational experience" of which I am aware, neither of those > deliverables has yet become real. Are you aware otherwise? Unfortunately, no. And as I have indicated on this mailing list I'm not sure the IETF approach for multihoming in IPv6 (shim6) is a realistic solution to the need to multihome for the foreseeable future. > Sticking with the "no PI space" mantra for IPv6 in the absence of > viable > multihoming and/or easy renumbering is just plain wrong. We need to > come > up with a criteria for PI space that will constrain the recipient pool > to > a reasonably small set of large institutions, i.e. those who will be > multi-homing and for whom renumbering would be a major and painful > task. It can, of course, be argued that renumbering networks that do not have a dedicated IT staff or significant technical expertise can also be a painful task (albeit not as major as a large enterprise). In fact, I suspect the cost of this sort of renumbering will likely create a market for NATv6, but I know saying that is heretical... To be clear, I am not sticking with any particular mantra, I was simply pointing out the reality of the situation. It can be convincingly argued that in the lifetime of IPv6, technology will advance such that any number of prefixes that might be created could be handled, just as the routing table growth of IPv4 was handled (although I'd personally prefer it be handled a bit less ... stressfully). It can also be convincingly argued that (to paraphrase Dave Clark) the IPv6 truck is driving into the same swamp as IPv4, yelling "me too, me too". Simply, renumbering sucks. Not being able to multi-home in a way that doesn't impact the DFZ sucks. Creating a "pioneer's reward" can also suck in the inequities that are created, particularly when a limited resource (routing slots) becomes scarce (e.g., I personally experienced the implications of this inequity when trying to explain that despite the fact that (at the time) Stanford had a /8 was not sufficient justification for 20 /8s and 20,000 /16s for the entire country of China). Everything has a cost. The question isn't either/or, it is a question of where we draw lines. > I invite all PPML readers to help us to reach that goal... As do I. Rgds, -drc From randy at psg.com Wed Apr 20 16:42:44 2005 From: randy at psg.com (Randy Bush) Date: Wed, 20 Apr 2005 10:42:44 -1000 Subject: [ppml] 2005-1:Business Need for PI Assignments References: <8D528F7C177242458A7AB5C5C13B675F1CC232@oak.cit.office> Message-ID: <16998.48836.771219.760224@roam.psg.com> *nobody* likes to renumber, end users, isps, ... and some of us speak from serious experience doing so. no organization wants to rely on any other organization for their address space. when viewed through very small glasses, it makes perfect business sense. end sites don't want to rely on isps. isps would prefer not to have to go through the rirs. rirs would prefer not to go through iana. and the iana does not want to be responsible to anybody. all nice, but give me a break. this is a global network; wear larger glasses. the promises of easy renumbering etc. in ipv6 were total bs. the promises of routing table limitation in ipv6 have turned out the same. no one who has been around the block is willing to bet one bowl of ugali that the ivtf or anyone else is going to come up with routing and multi-homing magic in the next five years. some of us doubt the problem will be solved at all usefully for real operations for far longer than five years, though we would dearly and desperately love to be proven wrong, and are contributing to the effort to prove ourselves wrong. no one actually knows, in a measurement sense, the elasticity of the global bgp routing system. but folk who are responsible for budgets, engineering networks, and deploying routers do know that being able to have enough horses to haul the load is having a serious impact on capex, and are not made happy at the thought of rampant routing growth on either their margins or on the technical stability of the internet. those of us with grayer and/or less hair have actually seen real global routing crashes, and don't want to explain them to the nyt, dhs, or clueless power grabbers in well-cut suits again. folk actually measuring ipv6 deployment know that the actual *use* of ipv6 is negligible at best, in north america, south america, europe, africa, oceania, and asia all rolled together. read the previous sentence again, actual use of ipv6 is negligible at best. likely there are more ipv6 address assigned than there are packets pushed in a day. it's still research lab stuff. and we all know in our black little hearts that the most significant factor in this is that ipv6 does not really offer the u$er anything that they can perceive sufficiently to spend money to start moving actual use or operations to v6. the end user does not know or care about address space, renumbering, nats, ... they just want their mtv, and are only willing to pay $19.95 a month for it. in a sense, this is good, users should not have to care about all the stuff we have to care about; you should not have to be a mechanic to drive a car. sure, we need to allow folk who really need and can justify (e.g. see drc's msg of earlier today) end site allocations to get them, both in v4 and v6, and in a consistent manner [ note that i have been pushing micro-allocation in ipv4 for many years, with long and strong resistance from cjw, and other folk now becoming more liberal in the v6 world ]. but, as no one has yet to come up with any of the promised magic, we really have no basis to predict the future other than some epsilon off the lessons of the past. and some of those lessons are o routing tables do make global messes when not treated with prudence and conservation. o when there is user and business incentive to do so, sites, isps, users, ... will go through the pains of dealing with rirs, provider space, ... o it is hard to find a good compromise in this space, but we have to do so, and have been doing so for a long while; do not panic. o but imprudent blow-out of any one (or more) of the dimensions in tension, at the expense of the others, will lead to articles in the nyt, wsj, and people who wear strange clothes. this is not easy. there are no simple answers of which i am aware. and progress will not be fast, certainly not enough to be a marketing force for ipv6. but, history tells us that if we are not careful, we pay big-time in the long run. randy From randy at psg.com Wed Apr 20 16:44:15 2005 From: randy at psg.com (Randy Bush) Date: Wed, 20 Apr 2005 10:44:15 -1000 Subject: [ppml] ARIN Certificates References: <6.0.1.1.2.20050421063020.03cded80@localhost> Message-ID: <16998.48927.155536.313492@roam.psg.com> perhaps having to have a different cert from each rir with which one deals is not the best solution for the global internet? is the nro considering a single cert authority? randy From dr at cluenet.de Wed Apr 20 16:56:39 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 20 Apr 2005 22:56:39 +0200 Subject: [ppml] ARIN Certificates In-Reply-To: <16998.48927.155536.313492@roam.psg.com> References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> Message-ID: <20050420205639.GA24586@srv01.cluenet.de> On Wed, Apr 20, 2005 at 10:44:15AM -1000, Randy Bush wrote: > perhaps having to have a different cert from each rir with which > one deals is not the best solution for the global internet? is > the nro considering a single cert authority? And while we're at it, can we please have a single IP allocation/assignment database, with a consistent autorization and authentication scheme, with all the IRR information tied to is (unlike RADB where everyone can enter what he/she likes)? Oh, sorry, I'm dreaming. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From lea.roberts at stanford.edu Wed Apr 20 17:57:43 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Wed, 20 Apr 2005 14:57:43 -0700 (PDT) Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <16998.48836.771219.760224@roam.psg.com> Message-ID: dear Randy - thanks for a very thoughtful (and thought-provoking) rant (and don't forget to :-). I hope we can come up with some criteria that will break the current log-jam while being as careful as possible. I hope (and am fairly confident) that you will continue to provide your viewpoint on our efforts. /Lea On Wed, 20 Apr 2005, Randy Bush wrote: > > > *nobody* likes to renumber, end users, isps, ... and some of us > speak from serious experience doing so. > > no organization wants to rely on any other organization for their > address space. when viewed through very small glasses, it makes > perfect business sense. end sites don't want to rely on isps. > isps would prefer not to have to go through the rirs. rirs would > prefer not to go through iana. and the iana does not want to be > responsible to anybody. all nice, but give me a break. this is a > global network; wear larger glasses. > > the promises of easy renumbering etc. in ipv6 were total bs. the > promises of routing table limitation in ipv6 have turned out the > same. > > no one who has been around the block is willing to bet one bowl of > ugali that the ivtf or anyone else is going to come up with routing > and multi-homing magic in the next five years. some of us doubt > the problem will be solved at all usefully for real operations for > far longer than five years, though we would dearly and desperately > love to be proven wrong, and are contributing to the effort to > prove ourselves wrong. > > no one actually knows, in a measurement sense, the elasticity of > the global bgp routing system. but folk who are responsible for > budgets, engineering networks, and deploying routers do know that > being able to have enough horses to haul the load is having a > serious impact on capex, and are not made happy at the thought of > rampant routing growth on either their margins or on the technical > stability of the internet. those of us with grayer and/or less > hair have actually seen real global routing crashes, and don't want > to explain them to the nyt, dhs, or clueless power grabbers in > well-cut suits again. > > folk actually measuring ipv6 deployment know that the actual *use* > of ipv6 is negligible at best, in north america, south america, > europe, africa, oceania, and asia all rolled together. read the > previous sentence again, actual use of ipv6 is negligible at best. > likely there are more ipv6 address assigned than there are packets > pushed in a day. it's still research lab stuff. > > and we all know in our black little hearts that the most > significant factor in this is that ipv6 does not really offer the > u$er anything that they can perceive sufficiently to spend money to > start moving actual use or operations to v6. the end user does not > know or care about address space, renumbering, nats, ... they just > want their mtv, and are only willing to pay $19.95 a month for it. > in a sense, this is good, users should not have to care about all > the stuff we have to care about; you should not have to be a > mechanic to drive a car. > > sure, we need to allow folk who really need and can justify (e.g. > see drc's msg of earlier today) end site allocations to get them, > both in v4 and v6, and in a consistent manner [ note that i have > been pushing micro-allocation in ipv4 for many years, with long and > strong resistance from cjw, and other folk now becoming more > liberal in the v6 world ]. > > but, as no one has yet to come up with any of the promised magic, > we really have no basis to predict the future other than some > epsilon off the lessons of the past. and some of those lessons are > o routing tables do make global messes when not treated with > prudence and conservation. > o when there is user and business incentive to do so, sites, > isps, users, ... will go through the pains of dealing with > rirs, provider space, ... > o it is hard to find a good compromise in this space, but we have > to do so, and have been doing so for a long while; do not > panic. > o but imprudent blow-out of any one (or more) of the dimensions > in tension, at the expense of the others, will lead to articles > in the nyt, wsj, and people who wear strange clothes. > > this is not easy. there are no simple answers of which i am aware. > and progress will not be fast, certainly not enough to be a > marketing force for ipv6. but, history tells us that if we are not > careful, we pay big-time in the long run. > > randy > From william at elan.net Wed Apr 20 18:16:45 2005 From: william at elan.net (william(at)elan.net) Date: Wed, 20 Apr 2005 15:16:45 -0700 (PDT) Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: > I hope we can come up with some criteria that will break the current > log-jam while being as careful as possible. I've possible idea that has to do with how ip block assignments for webhosts were dealt with (back several years ago if some of you remember it was difficult issue as well). Basicly ARIN policy would strongly suggest that end-users who need ipv6 block first contact their ISP for it, but still allow organizations to come in and ask ARIN directly as well (as with current ipv4 policies) but in such a case they have to provide techical reason for such micro-assignment request and ARIN would collect these reasons and then on meetings report the statistics and based on the reasons that are being given, we can decide to modify the policies as necessary. This does not really resolve problems or offer long-term solution, but it would make it easier to work on such permanent solution later and to a degree it should limit how much ip space is requested right away as well. -- William Leibzon Elan Networks william at elan.net From tme at multicasttech.com Wed Apr 20 19:03:26 2005 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 20 Apr 2005 19:03:26 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <8D528F7C177242458A7AB5C5C13B675F1CC232@oak.cit.office> Message-ID: On Wed, 20 Apr 2005 13:43:50 -0600 "Randy Lindsey" wrote: > > We need to come up with a criteria for PI space that will constrain > > the recipient pool to a reasonably small set of large institutions, > > i.e. those who will be multi-homing and for whom renumbering would be > > a major and painful task. > > Not only large institutions find it painful and expensive to renumber. > Small ISP's take just as long, and relative to their size the expense is > as great or greater than for a large one. Remember staff resources are > proportional to size of the organization. Years ago it took my small > ISP months to migrate from one provider's /21 to another provider. > > The current IPv4 minimum of a /19 or /20 is already tough for small They can go for a smaller allocation if they are multi-homed, thanks to 2002-3 : http://www.arin.net/policy/index.html#four222 Regards Marshall Eubanks > ISP's to reach and eliminates nearly all end-user organizations (in the > larger context of millions of end-user organizations). I think the IPv6 > limit should target the same size of organization as the current IPv4 > limit does. If I multi-home and can qualify for a PI block under IPv4, > I should be able to get one in IPv6 too. > > Randy Lindsey > Colorado Information Technologies, Inc. > http://www.coinfotech.com > From paul at vix.com Wed Apr 20 22:07:21 2005 From: paul at vix.com (Paul Vixie) Date: Thu, 21 Apr 2005 02:07:21 +0000 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: Message from "Randy Lindsey" of "Wed, 20 Apr 2005 13:43:50 CST." <8D528F7C177242458A7AB5C5C13B675F1CC232@oak.cit.office> Message-ID: <20050421020721.4D15A13971@sa.vix.com> > Not only large institutions find it painful and expensive to renumber. > Small ISP's take just as long, and relative to their size the expense is > as great or greater than for a large one. Remember staff resources are > proportional to size of the organization. Years ago it took my small > ISP months to migrate from one provider's /21 to another provider. in the ietf it is considered reasonable to focus on engineering and operational expense and to ignore business models when standardizing something. in the RIRs, business models actually matter. the compelling issue for small isp's is that if they live in PA space they're effectively acting as a VAR for their upstream. if you ask a small isp in this position to renumber, they have to ask their downstreams to also renumber. these downstreams have to consider the alternative of switching to the old upstream so as to avoid the current renumbering event, or to switch to a larger (non-VAR) provider to avoid future renumbering events. this significantly weakens the competitive position of small isp's and is bad for the industry and for the community. in other words i agree with the text i quoted but my reasons are different. > The current IPv4 minimum of a /19 or /20 is already tough for small > ISP's to reach and eliminates nearly all end-user organizations (in the > larger context of millions of end-user organizations). I think the IPv6 > limit should target the same size of organization as the current IPv4 > limit does. If I multi-home and can qualify for a PI block under IPv4, > I should be able to get one in IPv6 too. with the provisos that address space cannot be guaranteed or even known by an RIR to be routeable, and that if/when the IPv6 routing table ever grows large enough to be a problem then a new equilibrium point will have to be found: i find this to be a sensible proposal. From owen at delong.com Wed Apr 20 22:44:24 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2005 19:44:24 -0700 Subject: [ppml] 2005-1 alternatives In-Reply-To: <42662F23.A7479931@ix.netcom.com> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> <6.0.1.1.2.20050420085434.038f77f0@localhost> <2147483647.1113956771@[172.17.1.152]> <42662F23.A7479931@ix.netcom.com> Message-ID: <2147483647.1114026264@imac-en0.delong.sj.ca.us> Agreed. However, I think we need to stop trying to address security or privacy at the internetwork layer. For security or privacy to be meaningful or scaleable, it has to be end-to-end, or, very close to that. Transport is, in my opinion, one level below the lowest point where it should really occur. Transport and Internetwork integrity is one thing, but, real security or privacy depends on end-to-end authentication, encryption, and verification. We're a long way from having that in a widely adoptable form. X.509 is proof of how easy it is to screw that up. Verisign is proof that even large organizations with a huge vested interest in making something work can't always (or often) get it right. However, since this is a Public Policy discussion, let's stick to what we can do within the context of ARIN policy. Until IETF has something with which to replace IPv6, we have to consider it the current vision for the future of IP. Anything further out is more appropriately discussed in the IETF. As such, give the current realities, I think that what was proposed in 2005-1 was about as good as we can make IPv6 assignment policy given current constraints. I'd like to hear from the people who opposed 2005-1 on what would make it more palatable. Owen --On Wednesday, April 20, 2005 3:29 AM -0700 Jeff Williams wrote: > Owen and all, > > By golly I agree with just about everything you said below. I would > add a couple of caveats. > > 1.) It is likely and in process/progress that Ipv6 will be supplanted > by more advanced and more secure Ip protocols... > > 2.) Concerns regarding privacy and security are becoming more and > more broad reaching. With Ipv6's shortcomings in this area, and > Ipsec still a mess, there is a good chance that Ipv6 may loose any > attractiveness it could have now... > > Owen DeLong wrote: > >> > But then the duality and implicit tensions of routing scaleability and >> > addresses utility goes back a very long way - the Routing and >> > Addressing Group of the IETF in the early 1990s was an early >> > incarnation of the same set of tensions relating to what makes routing >> > scale vs what makes addresses truly useful and convenient to use. >> > >> >> That is why I am becoming progressively more convinced that we need >> to separate these two functions. Addressing primarily provides an >> end-system identifier function. Unfortunately, because we have chosen >> to also use a portion of this Address to provide routing information as >> well, we have painted ourselves into a corner on these issues, >> repeatedly. >> >> I think it is time to take a step back and consider a more radical >> approach to separating these two functions. In the long run, I think we >> would do well to consider the possibility of eliminating prefixes from >> interdomain routing, and, instead, build a facility for looking up the >> origin-AS for a given prefix, and, routing strictly on origin-AS. >> WIthin a given AS, routing would occur as it does now, but, Interdomain >> routing is where we face table overflow, not intr-as routing. >> >> The bottom line is that IPv6 doesn't provide any benefits over IPv4 to >> most adopters today. IPv4 has provisions for getting PI space, and, >> people are using them because there are lots of things that just don't >> work right or sufficiently without it. IPv6 has not solved ANY of these >> problems. >> >> There are, as I see it, two solutions on the horizon for this situation >> in IPv6. The first is ULA, which, has most of the drawbacks of RFC-1918 >> address space, but, lacks the self-enforcing limits of RFC-1918 IPv4 >> address space. The reality is that absent a forcing function to keep >> ULA from getting routed globally (such as the inherent overlap issues >> with RFC-1918 space), market demands will become a forcing function >> driving more and more ISPs to route more and more ULA space. Absent >> this policy, or, one like it, there are three possible outcomes: >> >> 1. IPv6 adoption will continue to be delayed until such >> time as IPv4 space is virtually exhausted and there is >> no further possibility to limp along with IPv4. >> >> 2. IPv6 adopters will drive the global routing of ULA >> over time. >> >> 3. Most IPv6 adopters will find or fabricate a way to >> act as an LIR out of desperation to obtain PI space >> under existing policy. >> >> 4. All of the people who have very legitimate and well >> thought out needs for PI address space will simply fade into the >> woodwork and accept IPv6 as is with PA space and renumber >> whenever they have to. >> >> Of the 4, I can see any or some combination of all of the first 3 as >> being likely. I think that the fourth is what the current IETF >> proposals are banking on, and, I think that any real-world perspective >> will clearly show that there is absolutely no historical precedent or >> reason to believe that it is at all likely. >> >> Owen >> >> -- >> If this message was not signed with gpg key 0FE2AA3D, it's probably >> a forgery. >> >> ---------------------------------------------------------------------- >> -- >> >> Part 1.2 Type: application/pgp-signature >> Encoding: 7bit > > 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 > > -- 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 paul at vix.com Wed Apr 20 22:59:17 2005 From: paul at vix.com (Paul Vixie) Date: Thu, 21 Apr 2005 02:59:17 +0000 Subject: [ppml] black hole lists Message-ID: <20050421025917.065F713E4A@sa.vix.com> in today's meeting, william(at)elan mentioned some stuff about what he called "blacklists". as the original inventor, and as someone who's spent a lot of time listening to lawyers, i ask you all to please call them "black hole lists". i also offered a partial apologia for the existence of the phenomena of black hole lists in the internet economy. i mentioned an old argument between myself and john gilmore wherein he complained that even if my own (at that time) "MAPS RBL" was responsibly run (which he didn't say was possible), my example would inspire many others to do the same thing, sometimes for political or hate related reasons, often irresponsibly. i admitted that this was true (and it was) but i didn't know of an alternative: the internet had been invaded, and without an immune system i didn't see how things could continue. i still don't. as long as there is abuse, there will be black hole lists. and my closing comment today was "but if you want to kill black hole lists once and for all time, all you have to do is fund your abuse desks." someone asked me about this afterward and i told him "if abuse desks were properly staffed and trained and empowered to disco customers without lengthy approval processes, then the risk of subscribing to a black hole list would begin to outweigh the risk of not subscribing to any, and black hole lists would start to die off." i recognize that in a post-dot-com-bust economy it's hard to justify this kind of spending. those of you who refuse my abuse complaints on the basis that "it has a mime attachment, which could be a virus, and we're reading the abuse mailbox with microsoft outlook" are very probably doing the best you can. but for every $1B the industry doesn't spend proactively on abuse desk services, the industry will spend $5B on weak reactive handling, and lose an additional $5B due to false positives, overreactive / irresponsible black hole lists, lost opportunities, and lost credibility / trust. From owen at delong.com Wed Apr 20 23:41:24 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2005 20:41:24 -0700 Subject: [ppml] 2005-1 alternatives In-Reply-To: <16997.63874.469259.203133@roam.psg.com> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> <6.0.1.1.2.20050420085434.038f77f0@localhost> <16997.63874.469259.203133@roam.psg.com> Message-ID: <2147483647.1114029684@imac-en0.delong.sj.ca.us> --On Tuesday, April 19, 2005 8:41 PM -1000 Randy Bush wrote: >> and there is some doubting of the wisdom of the optimistic view of "well >> we'll solve that routing explosion problem when it 's clearly obvious >> that its about to go bang!". > > some of us remember how much work it took to fix this the last > time, and the damage to customers in the process. i do not think > the current use of the internet by society would tolerate a mess > of the scale we had in the early '90s, with entire international > isps down for days, etc. Fine, but, why do you think that providers routing ULA will be less of a mess? 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 Wed Apr 20 23:57:39 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2005 20:57:39 -0700 Subject: [ppml] 2005-1 alternatives In-Reply-To: <6.0.1.1.2.20050420220734.02410e00@localhost> References: <1b8a3ba951bdddb7356459dda0c03dc9@cnet.com> <6.0.1.1.2.20050420085434.038f77f0@localhost> <2147483647.1113956771@[172.17.1.152]> <6.0.1.1.2.20050420220734.02410e00@localhost> Message-ID: <2147483647.1114030659@imac-en0.delong.sj.ca.us> Agreed... That's why I'm trying to make life better on both fronts. One one hand, I'm working on a proposal for IETF that would, I think, allow incremental and beneficial steps towards separatin. On the other hand, I put forth this policy proposal in the hopes of making it possible to prevent a ULA land rush for routing table entries. Owen --On Wednesday, April 20, 2005 10:22 PM +1000 Geoff Huston wrote: > At 05:26 PM 20/04/2005, Owen DeLong wrote: >>> But then the duality and implicit tensions of routing scaleability and >>> addresses utility goes back a very long way - the Routing and Addressing >>> Group of the IETF in the early 1990s was an early incarnation of the >>> same set of tensions relating to what makes routing scale vs what makes >>> addresses truly useful and convenient to use. >> >> That is why I am becoming progressively more convinced that we need >> to separate these two functions. > > > Welcome to a well established area of consideration! > > There is a rich body of material that has been generated over as many > years as we've been thinking about packet networking. There are papers > dating back to the early 60's on this issue of what is currently referred > to as the id/loc split, and the topic space encompasses various forms of > routing paradigms, end host paradigms and their various forms of > interaction. In one sense its a wonderfully unconstrained place to think > in in the abstract, and it would be wonderful to see many more folk > should be thinking and working in this area than we have today. > > But in practical terms there are a myriad of constraints that needs to be > considered when you come down to the harshness of reality. Personally > I'm of the opinion that its safest, when considering what risks we want > to run, to assume that routing capability and functionality will pretty > much continue for some time yet to be what we see today, and also, for > some time yet addresses will continue to have the semantic overload of > entity identification and location identification. It's this rather > conservative view of the world as we know it that is a valid > consideration when looking at these kind of policy proposals, and yes, > there is an amazing level of tension between maximizing the utility and > stability of addresses, and maximizing the prospects of routing to > continue to pass these address tokens around the network. > > regard, > > Geoff > > > -- 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 Thu Apr 21 00:02:52 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2005 21:02:52 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: <20050420144822.36523.qmail@web52006.mail.yahoo.com> Message-ID: <2147483647.1114030972@imac-en0.delong.sj.ca.us> Yes, David, but, ULA is proof that we will not do so. Owen --On Wednesday, April 20, 2005 8:47 AM -0700 David Conrad wrote: > Ben, > > While I understand the position you put forward, if addresses are not > obtained from providers, then the address prefix will need to appear in > all default-free routers through which connectivity is desired. It is, > of course, true that at this point in time there is plenty of space in > the "global routing tables", the question is, will that last for the > lifetime of IPv6? > > Many people feel it would be wise to learn from previous mistakes. > > Rgds, > -drc > > On Apr 20, 2005, at 7:48 AM, Benjamin Crawford wrote: > >> It is extremely important to realize that >> organizations, with responsibilities to their >> customers and shareholders, will not be willing to >> move forward with IPv6 if their v6 allocations will be >> tied in to a specific service provider. This point >> was made by several representatives at the PPM in >> Orlando and needs to be given strong consideration. >> IPv6 acceptance will continue to be prolonged until a >> time that a policy or technology is put in to place >> that will not bind an organization to a service >> provider due to an IPv6 allocation. At this time, the >> policy should be supported to help get v6 off of the >> shelf and accepted by many of the businesses out there >> who are starting to look at this new protocol. -Ben Crawford >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> > -- 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 Thu Apr 21 00:07:16 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2005 21:07:16 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: <20050420144822.36523.qmail@web52006.mail.yahoo.com> <16998.30199.508204.447952@roam.psg.com> Message-ID: <2147483647.1114031236@imac-en0.delong.sj.ca.us> > I'm missing something here. This is what I am either assuming or think I > am hearing: > > 1) The RIRs require that ISPs be prepared to sign up 200 customers in 5 > years in order to get space (via the policy). Only ISPs can get space. > No. LIR, not ISP. This distinction is significant, because, for example, Chevron IT with 200 subsidiaries/locations/etc. (or just a plan to have that many in the next yyy timeframe) can qualify as an RIR (not picking on Cheveron, insert any company you wish). They don't have to be an ISP, or even really be providing connectivity under the current policy. Just address space. Of course, the impact on the routing table if they are not providing sole-source connectivity... Anyway, that's the current policy. > 2) Customers are having trouble with a technology that requires putting > faith into ISPs, an industry that has proven quite economically unstable > in recent years. > Yes. > 1+2 seems to imply that supply and demand will have a hard time > materializing. > Supply has materialized and met with resounding lack of demand. > How does IPv6 gain momentum when adopters at the edge of the network > (customers) can't get space without having to rely on (and pay money to) > a core infrastructure that has a poor (recent) track record for business > stability? > IPv6 has huge inertia already. It has been gaining ground very slowly for years. It will continue to do so until something occurs to make it more attractive to the real users of the internet. > (Thinking of a recent discussion of SSH vs. DNSSEC in another forum - > innovation at the edge vs innovation at the core and adoption rates.) > > I understand that from an engineering perspective, IPv6 addressing ought > to be handled by the ISP (the layer 3 service provider) (- that sounds > very POTS-like). But this seems hard to achieve when business is > considered. Engineering vs. Economics. > Even the POTS providers have been forced into address portability. 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 Thu Apr 21 00:14:56 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2005 21:14:56 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <8D528F7C177242458A7AB5C5C13B675F1CC232@oak.cit.office> References: <8D528F7C177242458A7AB5C5C13B675F1CC232@oak.cit.office> Message-ID: <2147483647.1114031696@imac-en0.delong.sj.ca.us> --On Wednesday, April 20, 2005 1:43 PM -0600 Randy Lindsey wrote: >> We need to come up with a criteria for PI space that will constrain >> the recipient pool to a reasonably small set of large institutions, >> i.e. those who will be multi-homing and for whom renumbering would be >> a major and painful task. > > Not only large institutions find it painful and expensive to renumber. > Small ISP's take just as long, and relative to their size the expense is > as great or greater than for a large one. Remember staff resources are > proportional to size of the organization. Years ago it took my small > ISP months to migrate from one provider's /21 to another provider. > However, small ISPs can already qualify for a /32 under existing policy, so, ISPs are not the issue for this policy. This policy provides for assignment only and does not address allocation. > The current IPv4 minimum of a /19 or /20 is already tough for small > ISP's to reach and eliminates nearly all end-user organizations (in the > larger context of millions of end-user organizations). I think the IPv6 > limit should target the same size of organization as the current IPv4 > limit does. If I multi-home and can qualify for a PI block under IPv4, > I should be able to get one in IPv6 too. > The current IPv4 minimum is /22. Has been for about a year now. 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 william at elan.net Thu Apr 21 02:20:49 2005 From: william at elan.net (william(at)elan.net) Date: Wed, 20 Apr 2005 23:20:49 -0700 (PDT) Subject: [ppml] black hole lists In-Reply-To: <20050421025917.065F713E4A@sa.vix.com> References: <20050421025917.065F713E4A@sa.vix.com> Message-ID: On Thu, 21 Apr 2005, Paul Vixie wrote: > in today's meeting, william(at)elan mentioned some stuff about what he > called "blacklists". as the original inventor, and as someone who's > spent a lot of time listening to lawyers, i ask you all to please call > them "black hole lists". I believe I called them "blocklists" as I don't like or use the term "blacklist". I know why you want it called "black hole list" but its several years too late to change it now... --- William Leibzon Elan Networks william at elan.net From jeroen at unfix.org Thu Apr 21 02:59:48 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 21 Apr 2005 08:59:48 +0200 Subject: [ppml] ARIN Certificates In-Reply-To: <20050420205639.GA24586@srv01.cluenet.de> References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <20050420205639.GA24586@srv01.cluenet.de> Message-ID: <1114066789.9920.5.camel@firenze.zurich.ibm.com> On Wed, 2005-04-20 at 22:56 +0200, Daniel Roesen wrote: > On Wed, Apr 20, 2005 at 10:44:15AM -1000, Randy Bush wrote: > > perhaps having to have a different cert from each rir with which > > one deals is not the best solution for the global internet? is > > the nro considering a single cert authority? > > And while we're at it, can we please have a single IP > allocation/assignment database, with a consistent autorization and > authentication scheme, with all the IRR information tied to is (unlike > RADB where everyone can enter what he/she likes)? The problem here is that IANA is apparently not supposed to be running a whois server, they have one but not for IP prefixes. If they would simply have a redirect server on there, pointing to the correct RIR, the complete "which RIR to query for this prefix" problem would be gone. Authorization could then still be handled by the RIR's separately, which is a nuisance for some very big global ISP's but oh well, I guess we'll have to live with that. The second problem is that there are currently 3 different whois servers softwares in use by the 5 RIR's: * APNIC + RIPE + AFRINIC use the RIPE whois server software * ARIN uses their own weird edition, which *still* does not support CIDR (which is a big nuisance with IPv6) * LACNIC uses a, it seems to be, modified ARIN server, thus no CIDR support either. The latter two have their own formats, which don't match up with the APNIC/RIPE/AFRINIC scheme, thus having one to always handle those two as special cases. First of all it would be a great thing to have ARIN have CIDR support, so one can ask for a prefix instead for having to calculate the netmask into class-based addresses, getting two, or more netnames back and having to pick one of those. Oh joy global internet ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From jwkckid1 at ix.netcom.com Thu Apr 21 06:36:21 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 21 Apr 2005 03:36:21 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments References: <8D528F7C177242458A7AB5C5C13B675F1CC232@oak.cit.office> <16998.48836.771219.760224@roam.psg.com> Message-ID: <42678221.3D4184F@ix.netcom.com> Randy and all, Thank you Randy for confirming what I had been saying sense 2001. But as I recall than your attitude was the opposite of what you are saying now... Interesting... Randy Bush wrote: > > > *nobody* likes to renumber, end users, isps, ... and some of us > speak from serious experience doing so. > > no organization wants to rely on any other organization for their > address space. when viewed through very small glasses, it makes > perfect business sense. end sites don't want to rely on isps. > isps would prefer not to have to go through the rirs. rirs would > prefer not to go through iana. and the iana does not want to be > responsible to anybody. all nice, but give me a break. this is a > global network; wear larger glasses. > > the promises of easy renumbering etc. in ipv6 were total bs. the > promises of routing table limitation in ipv6 have turned out the > same. > > no one who has been around the block is willing to bet one bowl of > ugali that the ivtf or anyone else is going to come up with routing > and multi-homing magic in the next five years. some of us doubt > the problem will be solved at all usefully for real operations for > far longer than five years, though we would dearly and desperately > love to be proven wrong, and are contributing to the effort to > prove ourselves wrong. > > no one actually knows, in a measurement sense, the elasticity of > the global bgp routing system. but folk who are responsible for > budgets, engineering networks, and deploying routers do know that > being able to have enough horses to haul the load is having a > serious impact on capex, and are not made happy at the thought of > rampant routing growth on either their margins or on the technical > stability of the internet. those of us with grayer and/or less > hair have actually seen real global routing crashes, and don't want > to explain them to the nyt, dhs, or clueless power grabbers in > well-cut suits again. > > folk actually measuring ipv6 deployment know that the actual *use* > of ipv6 is negligible at best, in north america, south america, > europe, africa, oceania, and asia all rolled together. read the > previous sentence again, actual use of ipv6 is negligible at best. > likely there are more ipv6 address assigned than there are packets > pushed in a day. it's still research lab stuff. > > and we all know in our black little hearts that the most > significant factor in this is that ipv6 does not really offer the > u$er anything that they can perceive sufficiently to spend money to > start moving actual use or operations to v6. the end user does not > know or care about address space, renumbering, nats, ... they just > want their mtv, and are only willing to pay $19.95 a month for it. > in a sense, this is good, users should not have to care about all > the stuff we have to care about; you should not have to be a > mechanic to drive a car. > > sure, we need to allow folk who really need and can justify (e.g. > see drc's msg of earlier today) end site allocations to get them, > both in v4 and v6, and in a consistent manner [ note that i have > been pushing micro-allocation in ipv4 for many years, with long and > strong resistance from cjw, and other folk now becoming more > liberal in the v6 world ]. > > but, as no one has yet to come up with any of the promised magic, > we really have no basis to predict the future other than some > epsilon off the lessons of the past. and some of those lessons are > o routing tables do make global messes when not treated with > prudence and conservation. > o when there is user and business incentive to do so, sites, > isps, users, ... will go through the pains of dealing with > rirs, provider space, ... > o it is hard to find a good compromise in this space, but we have > to do so, and have been doing so for a long while; do not > panic. > o but imprudent blow-out of any one (or more) of the dimensions > in tension, at the expense of the others, will lead to articles > in the nyt, wsj, and people who wear strange clothes. > > this is not easy. there are no simple answers of which i am aware. > and progress will not be fast, certainly not enough to be a > marketing force for ipv6. but, history tells us that if we are not > careful, we pay big-time in the long run. > > randy -- 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 Thu Apr 21 06:44:06 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 21 Apr 2005 03:44:06 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments References: Message-ID: <426783F4.85220CC2@ix.netcom.com> Lea and all, Conversely dear Lea, thank you for your anti-rant (and less than thought-provoking) anti-rant at that. Oh yes, and don't forget to CYA whenever you can, naturally... >;) Lea Roberts wrote: > dear Randy - > > thanks for a very thoughtful (and thought-provoking) rant (and don't > forget to :-). > > I hope we can come up with some criteria that will break the current > log-jam while being as careful as possible. I hope (and am fairly > confident) that you will continue to provide your viewpoint on our > efforts. /Lea > > On Wed, 20 Apr 2005, Randy Bush wrote: > > > > > > > *nobody* likes to renumber, end users, isps, ... and some of us > > speak from serious experience doing so. > > > > no organization wants to rely on any other organization for their > > address space. when viewed through very small glasses, it makes > > perfect business sense. end sites don't want to rely on isps. > > isps would prefer not to have to go through the rirs. rirs would > > prefer not to go through iana. and the iana does not want to be > > responsible to anybody. all nice, but give me a break. this is a > > global network; wear larger glasses. > > > > the promises of easy renumbering etc. in ipv6 were total bs. the > > promises of routing table limitation in ipv6 have turned out the > > same. > > > > no one who has been around the block is willing to bet one bowl of > > ugali that the ivtf or anyone else is going to come up with routing > > and multi-homing magic in the next five years. some of us doubt > > the problem will be solved at all usefully for real operations for > > far longer than five years, though we would dearly and desperately > > love to be proven wrong, and are contributing to the effort to > > prove ourselves wrong. > > > > no one actually knows, in a measurement sense, the elasticity of > > the global bgp routing system. but folk who are responsible for > > budgets, engineering networks, and deploying routers do know that > > being able to have enough horses to haul the load is having a > > serious impact on capex, and are not made happy at the thought of > > rampant routing growth on either their margins or on the technical > > stability of the internet. those of us with grayer and/or less > > hair have actually seen real global routing crashes, and don't want > > to explain them to the nyt, dhs, or clueless power grabbers in > > well-cut suits again. > > > > folk actually measuring ipv6 deployment know that the actual *use* > > of ipv6 is negligible at best, in north america, south america, > > europe, africa, oceania, and asia all rolled together. read the > > previous sentence again, actual use of ipv6 is negligible at best. > > likely there are more ipv6 address assigned than there are packets > > pushed in a day. it's still research lab stuff. > > > > and we all know in our black little hearts that the most > > significant factor in this is that ipv6 does not really offer the > > u$er anything that they can perceive sufficiently to spend money to > > start moving actual use or operations to v6. the end user does not > > know or care about address space, renumbering, nats, ... they just > > want their mtv, and are only willing to pay $19.95 a month for it. > > in a sense, this is good, users should not have to care about all > > the stuff we have to care about; you should not have to be a > > mechanic to drive a car. > > > > sure, we need to allow folk who really need and can justify (e.g. > > see drc's msg of earlier today) end site allocations to get them, > > both in v4 and v6, and in a consistent manner [ note that i have > > been pushing micro-allocation in ipv4 for many years, with long and > > strong resistance from cjw, and other folk now becoming more > > liberal in the v6 world ]. > > > > but, as no one has yet to come up with any of the promised magic, > > we really have no basis to predict the future other than some > > epsilon off the lessons of the past. and some of those lessons are > > o routing tables do make global messes when not treated with > > prudence and conservation. > > o when there is user and business incentive to do so, sites, > > isps, users, ... will go through the pains of dealing with > > rirs, provider space, ... > > o it is hard to find a good compromise in this space, but we have > > to do so, and have been doing so for a long while; do not > > panic. > > o but imprudent blow-out of any one (or more) of the dimensions > > in tension, at the expense of the others, will lead to articles > > in the nyt, wsj, and people who wear strange clothes. > > > > this is not easy. there are no simple answers of which i am aware. > > and progress will not be fast, certainly not enough to be a > > marketing force for ipv6. but, history tells us that if we are not > > careful, we pay big-time in the long run. > > > > randy > > 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 william at elan.net Thu Apr 21 05:23:49 2005 From: william at elan.net (william(at)elan.net) Date: Thu, 21 Apr 2005 02:23:49 -0700 (PDT) Subject: [ppml] ARIN Certificates In-Reply-To: <1114066789.9920.5.camel@firenze.zurich.ibm.com> References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <20050420205639.GA24586@srv01.cluenet.de> <1114066789.9920.5.camel@firenze.zurich.ibm.com> Message-ID: On Thu, 21 Apr 2005, Jeroen Massar wrote: > The problem here is that IANA is apparently not supposed to be running a > whois server, they have one but not for IP prefixes. IANA has been running whois server for many years (10+ ?). First for .us domains (even supported rwhois back then) and .int then at some point started for .arpa and they also added whois for all root domains (i.e. for tld name itself). IANA never ran whois for ip blocks but they do maintain list of which RIR and which whois server is to be used depending on what /8 it is: http://www.iana.org/assignments/ipv4-address-space and I also keep my own version of this (slightly different format with more info and better whois references) at: http://www.completewhois.com/iana-ipv4-addresses.txt > If they would simply have a redirect server on there, pointing to the > correct RIR, the complete "which RIR to query for this prefix" problem > would be gone. Authorization could then still be handled by the RIR's > separately, which is a nuisance for some very big global ISP's but oh > well, I guess we'll have to live with that. Redirection is not supported by whois protocol directly. However CRIPS/IRIS does have it and I expect when it comes out IANA will either maintain root for IP blocks (redirecting clients to proper RIR whois) or possibly they may decide to have NRO maintain the root. > The second problem is that there are currently 3 different whois servers > softwares in use by the 5 RIR's: > > * APNIC + RIPE + AFRINIC use the RIPE whois server software > * ARIN uses their own weird edition, which *still* does not support CIDR > (which is a big nuisance with IPv6) > * LACNIC uses a, it seems to be, modified ARIN server, thus no CIDR > support either. As far as I know LACNIC runs modified version of RIPE server - older version with additional custom support added for org data. They could possibly even move to regular current ripe server (as new ripe server now supports orgs), but I don't know if that is planned or not. But as I'm not from LACNIC so if there is anybody here who is, they should correct me if above is not right. > The latter two have their own formats, which don't match up with the > APNIC/RIPE/AFRINIC scheme, thus having one to always handle those two as > special cases. Note that in addition to RIRs there are also ip whois servers run by several country registrars, such as JPNIC, TWNIC, KRNIC, etc. None of those run ripe software and they do not support cidr searches either, so I would not say that they or ARIN are special cases, rather cidr search is special feature of ripe whois server. CRISP has common AREG format that will be supported across all RIRs and LIRs and that does have option to do search for special ip block (its NOT cidr, but you would specify exact range to search for, which means it is more powerfull feature then cidr). -- William Leibzon Elan Networks william at elan.net From Michael.Dillon at radianz.com Thu Apr 21 05:53:56 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 21 Apr 2005 10:53:56 +0100 Subject: [ppml] ARIN Certificates In-Reply-To: Message-ID: > In the members meeting, it was reported that cases of attempted > registration fraud have been observed. (Details I don't have...) I > asked about uptake on ARIN's certificate service > (http://www.arin.net/CA) and heard that the community hasn't been > taking advantage of this. > > Consider this a request for folks with ARIN POC's to look into this service... ARIN's CA service is incredibly complex and is essentially broken by design, from a human factors point of view. That's why the community hasn't been taking advantage of this. I'm curious why ARIN needs such a convoluted system of identity checking while my bank is satisfied with an exchange of information in person, and a letter sent to my home address. This is enough for them to establish my identity for the purposes of online transactions. If there really is a role for certificates in ARIN and there really is an easy way in which certificates can be used to log into a web application to update ARIN records and request services, then why don't we do that? Perhaps the real problem is the lack of technology vision and the misguided desire to maintain an incredibly archaic email based transaction system. Not to mention the archaic whois protocol and the archaic rwhois server software. Sometimes an organization needs to bite the bullet and move into the 21st century, sweep aside the old archaic infrastructure, and leverage the powerful, off-the-shelf tools that are available today. XML-RPC, SOAP, REST, LDAP, etc... --Michael Dillon From Michael.Dillon at radianz.com Thu Apr 21 05:57:07 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 21 Apr 2005 10:57:07 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <83981c6d44918a10e779dc2781f24f27@nominum.com> Message-ID: > It can also be > convincingly argued that (to paraphrase Dave Clark) the IPv6 truck is > driving into the same swamp as IPv4, yelling "me too, me too". If we don't have a commonly agreed definition of "swamp", then nobody is going to worry about driving into it. So, what is your definition of "IPv4 swamp" and what was wrong with this "swamp". --Michael Dillon From Michael.Dillon at radianz.com Thu Apr 21 06:15:06 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 21 Apr 2005 11:15:06 +0100 Subject: [ppml] ARIN Certificates In-Reply-To: <1114066789.9920.5.camel@firenze.zurich.ibm.com> Message-ID: > First of all it would be a great thing to have ARIN have CIDR support, > so one can ask for a prefix instead for having to calculate the netmask > into class-based addresses, getting two, or more netnames back and > having to pick one of those. Oh joy global internet ;) If ARIN is going to put resources into fixing their whois server, then would it be too much to ask for them to simply implement the RIPE server software, and jointly develop any changes necessary, so that the whole world can benefit from that work? The end result is that ARIN spends less money and gets more benefits, than if we continue the old insular practice of hanging on to the first proof-of-concept version of software tools. --Michael Dillon From dr at cluenet.de Thu Apr 21 06:40:22 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 21 Apr 2005 12:40:22 +0200 Subject: [ppml] ARIN Certificates In-Reply-To: References: <1114066789.9920.5.camel@firenze.zurich.ibm.com> Message-ID: <20050421104022.GA32455@srv01.cluenet.de> On Thu, Apr 21, 2005 at 11:15:06AM +0100, Michael.Dillon at radianz.com wrote: > If ARIN is going to put resources into fixing their whois > server, then would it be too much to ask for them to simply > implement the RIPE server software, and jointly develop any > changes necessary, so that the whole world can benefit from > that work? I can only support this idea. This would also help to bring sensible authorization+authentication schemes to IRR in ARIN-land. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From easmith at beatrice.rutgers.edu Thu Apr 21 11:41:44 2005 From: easmith at beatrice.rutgers.edu (Ed Allen Smith) Date: Thu, 21 Apr 2005 11:41:44 -0400 Subject: [ppml] black hole lists In-Reply-To: <20050421025917.065F713E4A@sa.vix.com> References: <20050421025917.065F713E4A@sa.vix.com> Message-ID: In message <20050421025917.065F713E4A at sa.vix.com> (on 21 April 2005 02:59:17 +0000), paul at vix.com (Paul Vixie) wrote: >in today's meeting, william(at)elan mentioned some stuff about what he >called "blacklists". as the original inventor, and as someone who's >spent a lot of time listening to lawyers, i ask you all to please call >them "black hole lists". Why? If it's because it sounds non-PC to juries, that's an answer I can accept, BTW. How about "blocklists"? I also have to wonder what an OK-sounding-to-juries name would be for "whitelists"... >i still don't. as long as there is abuse, there will be black hole >lists. and my closing comment today was "but if you want to kill >black hole lists once and for all time, all you have to do is fund >your abuse desks." someone asked me about this afterward and i told >him "if abuse desks were properly staffed and trained and empowered >to disco customers without lengthy approval processes, then the risk >of subscribing to a black hole list would begin to outweigh the risk >of not subscribing to any, and black hole lists would start to die off." Depends on how you mean it. Not all reasons for blacklists/blocklists/whatever are for abuse - some of it is more like a shared version of a USENET killfile. (Some lists can perhaps be described as mixtures - some annoying behaviors such as lack of RFC compliance in various ways (http://www.rfc-ignorant.org) are correlated with abuse or other behaviors which are harmful but _sometimes_ not deliberately so.) But yes, the uses of more significance for this list's topic are indeed anti-abuse in orientation. -Allen -- Allen Smith http://cesario.rutgers.edu/easmith/ September 11, 2001 A Day That Shall Live In Infamy II "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin From david.conrad at nominum.com Thu Apr 21 09:51:07 2005 From: david.conrad at nominum.com (David Conrad) Date: Thu, 21 Apr 2005 06:51:07 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: <04d489c7597cb23df0824467308f859f@nominum.com> Michael, On Apr 21, 2005, at 2:57 AM, Michael.Dillon at radianz.com wrote: >> It can also be >> convincingly argued that (to paraphrase Dave Clark) the IPv6 truck is >> driving into the same swamp as IPv4, yelling "me too, me too". > > If we don't have a commonly agreed definition of "swamp", then > nobody is going to worry about driving into it. > > So, what is your definition of "IPv4 swamp" and what was > wrong with this "swamp". One definition of "the swamp" from draft-ietf-grow-rfc1519bis-00.txt is: "Note that, as defined, this plan neither requires nor assumes the re- assignment of those parts of the legacy "class C" space that are not amenable to aggregation (sometimes called "the swamp")." Since we're talking about IPv6, I'd think it would make sense to generalize this definition to be the unaggregatable prefixes in either global address pool. Rgds, -drc From andrew.dul at quark.net Thu Apr 21 12:37:18 2005 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 21 Apr 2005 16:37:18 +0000 Subject: [ppml] v6 PI space and Edu Message-ID: <20050421163718.13760.qmail@hoster908.com> I don't know the current status of v6 deployments of universities and other edu orgs around the region, but it certainly would be helpful to encouraging deployment if v6 was available to all those students with too much time on their hands. :) Under the current v6 allocation scheme it would be unlikely that a university could get a direct ARIN allocation unless the operated a "network" that served served multiple customers. I can think of a number of university network groups that would qualify, but I doubt that all will. Seems to me that it only makes sense to promote v6 deployments in edu, if that means 1 prefix in the routing table for each major university that seems reasonable to me. Perhaps the "breakthrough app" for North America would come from there... Andrew From dogwallah at gmail.com Thu Apr 21 13:47:59 2005 From: dogwallah at gmail.com (McTim) Date: Thu, 21 Apr 2005 20:47:59 +0300 Subject: [ppml] v6 PI space and Edu In-Reply-To: <20050421163718.13760.qmail@hoster908.com> References: <20050421163718.13760.qmail@hoster908.com> Message-ID: hello, On 4/21/05, Andrew Dul wrote: > > Under the current v6 allocation scheme it would be unlikely that a university could get a > direct ARIN allocation unless the operated a "network" that served served multiple > customers. Under the current scheme, they might not, depending on how they and ARIN interpret the phrase "other organizations" in the criteria from http://arin.net/policy/index.html#six51 "To qualify for an initial allocation of IPv6 address space, an organization must: (snip) d) be an existing, known ISP in the ARIN region or have a plan for making at least 200 /48 assignments to other organizations within five years." If each department/organisational unit of the university is considered as a different "organization" then many universities who are also LIRs could qualify. If the policy said "customers" and the LIR treated students as such, then it would be easier to meet the criteria. > Seems to me that it only makes sense to promote v6 deployments in edu, if that means 1 prefix in the routing table for each major university that seems reasonable to me. Agreed. Regards, McTim From Ed.Lewis at neustar.biz Thu Apr 21 14:57:59 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 21 Apr 2005 14:57:59 -0400 Subject: [ppml] ARIN Certificates In-Reply-To: <16998.48927.155536.313492@roam.psg.com> References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> Message-ID: At 10:44 -1000 4/20/05, Randy Bush wrote: >perhaps having to have a different cert from each rir with which >one deals is not the best solution for the global internet? is >the nro considering a single cert authority? I think that it would be an admirable goal...but ...There's something to be said for the fact that the 5 RIR's are separate organizations, loosely joined by having comparable policies yet retaining independence. ...It's not clear to me that the NRO is to have that much of a functional role. Perhaps the RIRs can someday accept each other's root certificates - that would need some discussion and review. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From randy at psg.com Thu Apr 21 15:02:24 2005 From: randy at psg.com (Randy Bush) Date: Thu, 21 Apr 2005 09:02:24 -1000 Subject: [ppml] ARIN Certificates References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> Message-ID: <16999.63680.262762.429868@roam.psg.com> >> perhaps having to have a different cert from each rir with which >> one deals is not the best solution for the global internet? is >> the nro considering a single cert authority? > > I think that it would be an admirable goal...but > > ...There's something to be said for the fact that the 5 RIR's are > separate organizations, loosely joined by having comparable policies > yet retaining independence. hey, i'm just trying to get a usable operational cert, not delve into irr, iana, dhs, ... politics. e.g., as sbgp rolls out, am i going to have sign my euro prefixes with a ripe cert, my asian ... i think you get it. > ...It's not clear to me that the NRO is to have that much of a > functional role. Perhaps the RIRs can someday accept each other's > root certificates - that would need some discussion and review. then maybe iana should be the root ca randy From paul at vix.com Thu Apr 21 16:39:45 2005 From: paul at vix.com (Paul Vixie) Date: Thu, 21 Apr 2005 20:39:45 +0000 Subject: [ppml] black hole lists In-Reply-To: Message from Ed Allen Smith of "Thu, 21 Apr 2005 11:41:44 -0400." Message-ID: <20050421203945.29C5313971@sa.vix.com> > > in today's meeting, william(at)elan mentioned some stuff about what > > he called "blacklists". as the original inventor, and as someone > > who's spent a lot of time listening to lawyers, i ask you all to > > please call them "black hole lists". > > Why? does it matter? i coined the term -- i get to say what i meant. > If it's because it sounds non-PC to juries, that's an answer I can > accept, BTW. it's because of a possible implied intent do to harm. > How about "blocklists"? I also have to wonder what an > OK-sounding-to-juries name would be for "whitelists"... blocklist is just as bad. lawyers are funny. (and now we're funny too.) > > ..., then the risk of subscribing to a black hole list would begin > > to outweigh the risk of not subscribing to any, and black hole lists > > would start to die off." > > Depends on how you mean it. Not all reasons for > blacklists/blocklists/whatever are for abuse - some of it is more like a > shared version of a USENET killfile. i dare say that non-reputational lists aren't creating the operational problems that made william(at)elan mention this on the remote participation channel of this week's arin meeting. From steve at blighty.com Thu Apr 21 17:59:24 2005 From: steve at blighty.com (Steve Atkins) Date: Thu, 21 Apr 2005 14:59:24 -0700 Subject: [ppml] black hole lists In-Reply-To: <20050421203945.29C5313971@sa.vix.com> References: <20050421203945.29C5313971@sa.vix.com> Message-ID: <20050421215924.GA31167@gp.word-to-the-wise.com> On Thu, Apr 21, 2005 at 08:39:45PM +0000, Paul Vixie wrote: > > > please call them "black hole lists". > > > > Why? > > does it matter? i coined the term -- i get to say what i meant. If it's used to create blackhole routes then "black hole list" is clearly an appropriate term, as it describes the intended usage. For lists that are not intended to be used to create blackhole routes, it doesn't seem to me to be an accurate description. > > If it's because it sounds non-PC to juries, that's an answer I can > > accept, BTW. > > it's because of a possible implied intent do to harm. The intent of some of the lists is to do harm, in as much as blocking email is harmful to the sender. (For the "subjective" lists such as the MAPS RBL or the SpamHaus SBL, rather than the "objective" lists such as the CBL, DUL, BOPM, etc). However, the dictionary description I have handy for "blacklist" is "n. a list of people who are out of favor" which seem a perfectly accurate description of the subjective lists. (Not that this is the mailing list to have this discussion at any great length, of course). Cheers, Steve From gih at apnic.net Thu Apr 21 18:19:20 2005 From: gih at apnic.net (Geoff Huston) Date: Fri, 22 Apr 2005 08:19:20 +1000 Subject: [ppml] ARIN Certificates In-Reply-To: <16999.63680.262762.429868@roam.psg.com> References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> Message-ID: <6.0.1.1.2.20050422081536.04da17d0@localhost> At 05:02 AM 22/04/2005, Randy Bush wrote: > >> perhaps having to have a different cert from each rir with which > >> one deals is not the best solution for the global internet? is > >> the nro considering a single cert authority? > > > > I think that it would be an admirable goal...but > > > > ...There's something to be said for the fact that the 5 RIR's are > > separate organizations, loosely joined by having comparable policies > > yet retaining independence. > >hey, i'm just trying to get a usable operational cert, not delve >into irr, iana, dhs, ... politics. > >e.g., as sbgp rolls out, am i going to have sign my euro prefixes >with a ripe cert, my asian ... i think you get it. > > > ...It's not clear to me that the NRO is to have that much of a > > functional role. Perhaps the RIRs can someday accept each other's > > root certificates - that would need some discussion and review. > >then maybe iana should be the root ca well some considerations of getting this thing done as opposed to talking about it says to me that we run with what should work now, which says to me that an NRO root cert makes sense in the first instance. Your point about have a single cert for a single entity with resources from multiple RIRs is a good one. Having multiple certificates does not work and there is a certain amount of coordination process to ensure that there is one entity and one cert attribute.. Of course there are then multiple update and potential revocation sources, and I suspect that the entity will need to actively consent to such an arrangement beforehand. Geoff From randy at psg.com Thu Apr 21 19:04:42 2005 From: randy at psg.com (Randy Bush) Date: Thu, 21 Apr 2005 13:04:42 -1000 Subject: [ppml] ARIN Certificates References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> <6.0.1.1.2.20050422081536.04da17d0@localhost> Message-ID: <17000.12682.790329.720123@roam.psg.com> > well some considerations of getting this thing done as opposed to talking > about it says to me that we run with what should work now, which says to me > that an NRO root cert makes sense in the first instance. i suspect that isps will be signing requests for number space, for domain names, to attest to bgp announcements, ... within the isp, one will have the isp's cert signing certs for these many different roles. it would be cool if the isp needed only one isp cert to be able to use it to sign the certs for all the roles. at the moment, the iana is the only place where all these roles converge. otoh, i do understand your frustration at even contemplating what it would take to get the iana to understand the job and to actually be able to execute it with useful rigor and alacrity. > Having multiple certificates does not work and there is a certain > amount of coordination process to ensure that there is one entity > and one cert attribute.. Of course there are then multiple update > and potential revocation sources, and I suspect that the entity > will need to actively consent to such an arrangement beforehand. i don't think that i, for one, will be inclined to agree to having any rir, nro, ... revoke my cert for any reason other than my specifically requesting it in an extremely well authenticated manner. "dear customer: we can no longer announce your prefix because apnic has revoked our certificate due to a billing problem and our bgp neighbors will no longer accept our sbgp announcements. of course, you may not get this email, so what the heck." not a chance in hell. a cert is your certifying my identity, not my membership or billing status. somewhat analogously, if an rir has an expire on an address prefix cert which is linked to rir billing cycles, then, in the sbgp world, it sure looks very clearly like rental of address space, not a business or legal place i suspect that rirs, isps, or any parts of the community want to go. randy From sanjaya at apnic.net Thu Apr 21 19:46:44 2005 From: sanjaya at apnic.net (Sanjaya) Date: Fri, 22 Apr 2005 09:46:44 +1000 Subject: [ppml] ARIN Certificates In-Reply-To: <17000.12682.790329.720123@roam.psg.com> References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> <6.0.1.1.2.20050422081536.04da17d0@localhost> <17000.12682.790329.720123@roam.psg.com> Message-ID: <42683B64.7080603@apnic.net> Randy Bush wrote: > "dear customer: we can no longer announce your prefix because > apnic has revoked our certificate due to a billing problem and > our bgp neighbors will no longer accept our sbgp announcements. > of course, you may not get this email, so what the heck." > > not a chance in hell. a cert is your certifying my identity, not > my membership or billing status. I can see your point Randy. But what would an ISP do if a customer defaulted their payment? Wouldn't you stop the service? Wouldn't the customer lose their 'right to use' (using RFC3779 terminology) the prefix? Cheers, Sanjaya From randy at psg.com Thu Apr 21 19:52:32 2005 From: randy at psg.com (Randy Bush) Date: Thu, 21 Apr 2005 13:52:32 -1000 Subject: [ppml] ARIN Certificates References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> <6.0.1.1.2.20050422081536.04da17d0@localhost> <17000.12682.790329.720123@roam.psg.com> <42683B64.7080603@apnic.net> Message-ID: <17000.15552.698086.339749@roam.psg.com> > I can see your point Randy. But what would an ISP do if a > customer defaulted their payment? Wouldn't you stop the service? > Wouldn't the customer lose their 'right to use' (using RFC3779 > terminology) the prefix? we're talking about inability to route, not some bureaucratic administrivia, the real internet. randy From randy at psg.com Thu Apr 21 19:59:25 2005 From: randy at psg.com (Randy Bush) Date: Thu, 21 Apr 2005 13:59:25 -1000 Subject: [ppml] ARIN Certificates References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> <6.0.1.1.2.20050422081536.04da17d0@localhost> <17000.12682.790329.720123@roam.psg.com> <42683B64.7080603@apnic.net> <17000.15552.698086.339749@roam.psg.com> Message-ID: <17000.15965.131366.154767@roam.psg.com> >> I can see your point Randy. But what would an ISP do if a >> customer defaulted their payment? Wouldn't you stop the service? >> Wouldn't the customer lose their 'right to use' (using RFC3779 >> terminology) the prefix? > we're talking about inability to route, not some bureaucratic > administrivia, the real internet. to prattle on. the rirs have always said "we do not control routing or routability." with x.509 attested prefix ownership, the certs in the chain do control it. one suggests that any such control be exercised *extremely* lightly, downright minimally. randy From sanjaya at apnic.net Thu Apr 21 20:22:57 2005 From: sanjaya at apnic.net (Sanjaya) Date: Fri, 22 Apr 2005 10:22:57 +1000 Subject: [ppml] ARIN Certificates In-Reply-To: <17000.15965.131366.154767@roam.psg.com> References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> <6.0.1.1.2.20050422081536.04da17d0@localhost> <17000.12682.790329.720123@roam.psg.com> <42683B64.7080603@apnic.net> <17000.15552.698086.339749@roam.psg.com> <17000.15965.131366.154767@roam.psg.com> Message-ID: <426843E1.4070104@apnic.net> Randy Bush wrote: > to prattle on. the rirs have always said "we do not control > routing or routability." with x.509 attested prefix ownership, > the certs in the chain do control it. one suggests that any such > control be exercised *extremely* lightly, downright minimally. > > randy Point taken. The certification process should be clearly defined and approved by the membership of the RIR I should think. Cheers, Sanjaya From randy at psg.com Thu Apr 21 20:33:41 2005 From: randy at psg.com (Randy Bush) Date: Thu, 21 Apr 2005 14:33:41 -1000 Subject: [ppml] ARIN Certificates References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> <6.0.1.1.2.20050422081536.04da17d0@localhost> <17000.12682.790329.720123@roam.psg.com> <42683B64.7080603@apnic.net> <17000.15552.698086.339749@roam.psg.com> <17000.15965.131366.154767@roam.psg.com> <426843E1.4070104@apnic.net> Message-ID: <17000.18021.753315.148355@roam.psg.com> >> to prattle on. the rirs have always said "we do not control >> routing or routability." with x.509 attested prefix ownership, >> the certs in the chain do control it. one suggests that any such >> control be exercised *extremely* lightly, downright minimally. > Point taken. The certification process should be clearly defined and > approved by the membership of the RIR I should think. this has the potential to be a very big bomb. one of the biggest concerns in the secure routing arena is the abuse of the security facility to be used as a severe denial of service. routing is global, not just one rir at a time. the stakeholders are not just the folk doing address allocation in the isps, but every prefix-owning entity in the global internet. i.e. the set of stakeholders is very weakly represented in the rirs, a classic problem, but one that has to be taken seriously considering the threat model here. if the rirs can not be *exceedingly* well trusted to not damage the routing of the isps, then the simple approach would be for the isps to just get their certs from a normal commercial (or free) ca. this may be the wiser course anyway. randy From bmanning at vacation.karoshi.com Thu Apr 21 21:34:15 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Apr 2005 01:34:15 +0000 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <04d489c7597cb23df0824467308f859f@nominum.com> References: <04d489c7597cb23df0824467308f859f@nominum.com> Message-ID: <20050422013415.GA4796@vacation.karoshi.com.> On Thu, Apr 21, 2005 at 06:51:07AM -0700, David Conrad wrote: > On Apr 21, 2005, at 2:57 AM, Michael.Dillon at radianz.com wrote: > >>It can also be > >>convincingly argued that (to paraphrase Dave Clark) the IPv6 truck is > >>driving into the same swamp as IPv4, yelling "me too, me too". > > > >If we don't have a commonly agreed definition of "swamp", then > >nobody is going to worry about driving into it. > > > >So, what is your definition of "IPv4 swamp" and what was > >wrong with this "swamp". > > One definition of "the swamp" from draft-ietf-grow-rfc1519bis-00.txt is: > > "Note that, as defined, this plan neither requires nor assumes the re- > assignment of those parts of the legacy "class C" space that are not > amenable to aggregation (sometimes called "the swamp")." > > Since we're talking about IPv6, I'd think it would make sense to > generalize this definition to be the unaggregatable prefixes in either > global address pool. > > Rgds, > -drc imho, there are -very few- prefixes that are NOT aggregatable. imho, it is useful, and HARD, to discriminate btwn aggregations that are approved by the prefix originator and proxy aggregations that are done w/o the knowledge/consent of the prefix originator. --bill From bmanning at vacation.karoshi.com Thu Apr 21 21:37:43 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Apr 2005 01:37:43 +0000 Subject: [ppml] v6 PI space and Edu In-Reply-To: <20050421163718.13760.qmail@hoster908.com> References: <20050421163718.13760.qmail@hoster908.com> Message-ID: <20050422013743.GB4796@vacation.karoshi.com.> Internet2 has an IPv6 block that is used for the Abilene network and the affiliated, connected universities. so there is single prefix that covers most of the higher ed (.edu in the US) sites for IPv6 transit. International education/research sites (non-.EDU) have similar plans/deployments in place. --bill On Thu, Apr 21, 2005 at 04:37:18PM +0000, Andrew Dul wrote: > I don't know the current status of v6 deployments of universities and other edu orgs around the region, but it certainly would be helpful to encouraging deployment if v6 was available to all those students with too much time on their hands. :) > > Under the current v6 allocation scheme it would be unlikely that a university could get a direct ARIN allocation unless the operated a "network" that served served multiple customers. I can think of a number of university network groups that would qualify, but I doubt that all will. > > Seems to me that it only makes sense to promote v6 deployments in edu, if that means 1 prefix in the routing table for each major university that seems reasonable to me. > > Perhaps the "breakthrough app" for North America would come from there... > > Andrew From Ed.Lewis at neustar.biz Thu Apr 21 21:38:34 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 21 Apr 2005 21:38:34 -0400 Subject: [ppml] ARIN Certificates In-Reply-To: <17000.12682.790329.720123@roam.psg.com> References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> <6.0.1.1.2.20050422081536.04da17d0@localhost> <17000.12682.790329.720123@roam.psg.com> Message-ID: At 13:04 -1000 4/21/05, Randy Bush wrote: >somewhat analogously, if an rir has an expire on an address prefix >cert which is linked to rir billing cycles, then, in the sbgp >world, it sure looks very clearly like rental of address space, not >a business or legal place i suspect that rirs, isps, or any parts >of the community want to go. Wow. Hadn't thought of the issue to that depth. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From gih at apnic.net Thu Apr 21 22:51:39 2005 From: gih at apnic.net (Geoff Huston) Date: Fri, 22 Apr 2005 12:51:39 +1000 Subject: [ppml] ARIN Certificates In-Reply-To: <17000.12682.790329.720123@roam.psg.com> References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> <6.0.1.1.2.20050422081536.04da17d0@localhost> <17000.12682.790329.720123@roam.psg.com> Message-ID: <6.0.1.1.2.20050422124558.04cf0eb0@localhost> At 09:04 AM 22/04/2005, Randy Bush wrote: > > well some considerations of getting this thing done as opposed to talking > > about it says to me that we run with what should work now, which says > to me > > that an NRO root cert makes sense in the first instance. > >i suspect that isps will be signing requests for number space, for >domain names, to attest to bgp announcements, ... within the isp, >one will have the isp's cert signing certs for these many different >roles. it would be cool if the isp needed only one isp cert to be >able to use it to sign the certs for all the roles. at the moment, >the iana is the only place where all these roles converge. > >otoh, i do understand your frustration at even contemplating what >it would take to get the iana to understand the job and to actually >be able to execute it with useful rigor and alacrity. In recent times IANA has been careful to take the time to understand the implications of undertaking new tasks and roles and has many calls on its resources. So I was voicing the opinion that it may be preferable to commence such a role with the resources we have at hand. Of course if you believe that rooting these certs at IANA as the root CA here from the start is essential, I'd be keen to understand the nature of requirement, and if that's the case then we probably need to exercise some patience to pull all this together, regards, Geoff From gih at apnic.net Thu Apr 21 23:04:53 2005 From: gih at apnic.net (Geoff Huston) Date: Fri, 22 Apr 2005 13:04:53 +1000 Subject: [ppml] ARIN Certificates In-Reply-To: <42683B64.7080603@apnic.net> References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> <6.0.1.1.2.20050422081536.04da17d0@localhost> <17000.12682.790329.720123@roam.psg.com> <42683B64.7080603@apnic.net> Message-ID: <6.0.1.1.2.20050422130030.04c4d490@localhost> At 09:46 AM 22/04/2005, Sanjaya wrote: >Randy Bush wrote: > >> "dear customer: we can no longer announce your prefix because >> apnic has revoked our certificate due to a billing problem and >> our bgp neighbors will no longer accept our sbgp announcements. >> of course, you may not get this email, so what the heck." >>not a chance in hell. a cert is your certifying my identity, not >>my membership or billing status. > >I can see your point Randy. But what would an ISP do if a customer >defaulted their payment? Wouldn't you stop the service? Wouldn't the >customer lose their 'right to use' (using RFC3779 terminology) the prefix? I think you are reading too much into this. CRLs are part of the certificate infrastructure, and to immediately leap to assumptions about the reasons for entering a cert on a CRL appears to me to be a distinct topic about certificate practices. If your question _really_ was Randy "would all RIRs use an identical CPL?" then I'm not sure that I have a clear idea of the Right Things and some discussion of that topic on this and related RIR forums would be, of course, helpful. regards, Geoff From randy at psg.com Thu Apr 21 23:21:08 2005 From: randy at psg.com (Randy Bush) Date: Thu, 21 Apr 2005 17:21:08 -1000 Subject: [ppml] ARIN Certificates References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <16999.63680.262762.429868@roam.psg.com> <6.0.1.1.2.20050422081536.04da17d0@localhost> <17000.12682.790329.720123@roam.psg.com> <42683B64.7080603@apnic.net> <6.0.1.1.2.20050422130030.04c4d490@localhost> Message-ID: <17000.28068.976177.705063@roam.psg.com> arin certs are available, and presumably renewable, if one has a signed agreement with arin for any reason. i.e. no aditional cost, requirements, ... i presume that this means that the cert is renewable no questions asked in the future. so i am not too worried about the certification of my identity in this case. i do not know whether this is or will be the mode with other rirs. then there are the certs which allow the site, isp, ... which has an asn and/or address block(s). if the issuers will promise to renew those certs with no further fuss, then it seems reasonable. i suspect that if, renewal or revocation of certificates which allow the site/isp/... to route packets is administratively encumbered more than it is today, those encumbering packet motion will quickly find themselves out of the certification business and in the courts. randy From owen at delong.com Fri Apr 22 02:28:30 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Apr 2005 23:28:30 -0700 Subject: [ppml] v6 PI space and Edu In-Reply-To: <20050421163718.13760.qmail@hoster908.com> References: <20050421163718.13760.qmail@hoster908.com> Message-ID: <2147483647.1114126109@[172.17.1.152]> Fictional example: We, Ferndale Underwater Controlled Kinetics University, propose to provide a V6 /48 to each of our 200 dorm rooms as well as IP services for the various departments, libraries, and administrative, and infrastructure facilities on the campus. As such, we wish to become an LIR. Given that we have 200 dorm rooms each of which is a customer, we believe that we qualify under the IPv6 policies for a direct ARIN allocation to us as an LIR. Guess what... The above complies with the policy and they would be able to do it. Do you really think that there is a university that can't come up with a plan for 200 downstream "customers" if they can count all their departments, admin, campus health, etc. and, if they provide IP services to students in their dorms, those count too? I think current policy more than adequately meets the needs of most colleges and universities. 2005-1 is really not aimed at anyone providing IP services. It is designed to facilitate the business use of IPv6, which, will not become reality without some form of PI or a real solution to easy renumbering without provider lockin. Owen --On Thursday, April 21, 2005 16:37 +0000 Andrew Dul wrote: > I don't know the current status of v6 deployments of universities and > other edu orgs around the region, but it certainly would be helpful to > encouraging deployment if v6 was available to all those students with too > much time on their hands. :) > > Under the current v6 allocation scheme it would be unlikely that a > university could get a direct ARIN allocation unless the operated a > "network" that served served multiple customers. I can think of a number > of university network groups that would qualify, but I doubt that all > will. > > Seems to me that it only makes sense to promote v6 deployments in edu, if > that means 1 prefix in the routing table for each major university that > seems reasonable to me. > Perhaps the "breakthrough app" for North America would come from there... > > Andrew -- 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 Fred.Wettling at bechtel.com Fri Apr 22 09:25:17 2005 From: Fred.Wettling at bechtel.com (Wettling, Fred) Date: Fri, 22 Apr 2005 09:25:17 -0400 Subject: [ppml] 2005-1:Multi-national Business Enablement Message-ID: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> ARIN Policy Proposal 2005-1 removes one of the current obstacles for the real-world deployment of IPv6 by multi-national businesses. Global enterprise address management is critical. Global businesses are also challenged with unique routing policy and multi-homed sites which are the criteria for assignment of an AS Numbers (ARIN Policy Section 5). Beyond multi-homing at multiple sites, businesses also concurrently deal with dozens of service providers around the planet in the deployment of IP-based enterprise WAN backbones. Proposal 2005-1 is solid and helps businesses in the effective planning, deployment. and management global enterprise IPv6 address spaces based on the established and well understood Autonomous System Number Guidelines. I encourage the Proposal 2005-1 comments to focus on how the adoption of IPv6 can be ENABLED for businesses with minimum complexity. Current standards and policies do not adequately address unique routing, multi-homing, and multiple service providers on a global basis Fred Wettling Bechtel Corporation Network Applications Consortium North American IPv6 Business Council From kloch at hotnic.net Fri Apr 22 10:18:17 2005 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 22 Apr 2005 10:18:17 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <16998.48836.771219.760224@roam.psg.com> References: <8D528F7C177242458A7AB5C5C13B675F1CC232@oak.cit.office> <16998.48836.771219.760224@roam.psg.com> Message-ID: <426907A9.4020208@hotnic.net> Randy Bush wrote: > o it is hard to find a good compromise in this space, but we have > to do so, and have been doing so for a long while; do not > panic. > o but imprudent blow-out of any one (or more) of the dimensions > in tension, at the expense of the others, will lead to articles > in the nyt, wsj, and people who wear strange clothes. > > this is not easy. there are no simple answers of which i am aware. > and progress will not be fast, certainly not enough to be a > marketing force for ipv6. but, history tells us that if we are not > careful, we pay big-time in the long run. It sounds like some aren't satisfied with the limited selectivity of ASN requirements. If only we had a knob like we have in IPv4 (number of virtual interfaces) to fine tune who qualifies for PI. That doesn't map well to IPv6, but we do have "x /48 ssignments in y timeframe" to work with. Create something like a "micro-LIR" category which is assumed to be mostly self serving but with a small allocation like /44. X and y could be something like 8 /48 assignments within 1 year. I'm sure most companies that we agree should qualify would have 7 business relationships (employees, vendors, customers, subsidiaries, POP's) that they could justify assigning /48's to. X, y and standards for the /48 assignemnts should provide enough variables to fine tune the policy for maximum aggregation and conservation. One (major imho) benefit of this would be making a clear distinction between the smallest RIR allocation and the standard end site /48. You would have to be careful to not steer actual ISP's into these micro-LIR allocations, because even the most unsuccessful ISP would quickly outgrow a /44 and cause fragmentation. The difference is an "ISP" is primarily in the business of aggregating and selling transit, while a micro-LIR aggregates and provides transit as a side effect of their primary business. You could throw on other requirements, but you would quickly make it more difficult to get a micro-LIR allocation than a /32 under the current policy. - Kevin From Michael.Dillon at radianz.com Fri Apr 22 11:11:09 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 22 Apr 2005 16:11:09 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <426907A9.4020208@hotnic.net> Message-ID: > > o but imprudent blow-out of any one (or more) of the dimensions > > in tension, at the expense of the others, will lead to articles > > in the nyt, wsj, and people who wear strange clothes. > Create something like a "micro-LIR" category which is assumed to be > mostly self serving but with a small allocation like /44. What is the point of this? One of the "dimensions in tension" is the number of routes in the global routing table. A dimension that is not in tension is the number of available IPv6 addresses in 2000::/3. You suggestion is to conserve the dimension not in tension but does nothing to conserve the dimension that is in tension. If a company receives an AS number then they can announce any number of prefixes into the global routing table. Why not give them a /32 knowing that in 99% of the cases, this company will never need an additional allocation and will therefore only need to announce one route entry? That does conserve a dimension in tension. God help us if we start to hand out /44's and then 5 years from now someone creates an IPv6 application that results in large numbers of /48 assignments, causing all the /44 allocations to run out and get a second one. Then, when we see the problem and adjust that /44 boundary up to /32, these organizations will once again overflow their 2nd /44 and get a 3rd /32 allocation. And then we realize that it is virtually impossible to renumber this application because it involves IPv6 addresses configured into hardware devices that have no central management capability. So now we have consumed 3 times as many global routing table entries as we would have by BEING CONSERVATIVE AND GIVING EVERYONE A /32! IPv6 is not IPv4. Being prudent and conservative in an IPv6 world involves different behaviors than being conservative in an IPv4 world. I'd like to point out that my IPv4 DSL provider gives me a /32 for my home DSL connection and they never even asked whether or not I had a router or a single PC. If this is justification enough to get one 4.3 billionth of the IPv4 address space, then why does a company need to go through contortions to justify one 4.3 billionth of the IPv6 address space? --Michael Dillon P.S. is anyone aware of an academic research organization that is doing a global study to try to determine how many IPv6 addresses might be needed in the various different regions of the world? Either a high level study or something as granular as metropolitan areas? From kloch at hotnic.net Fri Apr 22 11:49:01 2005 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 22 Apr 2005 11:49:01 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: <42691CED.7010305@hotnic.net> Michael.Dillon at radianz.com wrote: > If a company receives an AS number then they can announce > any number of prefixes into the global routing table. Why not > give them a /32 knowing that in 99% of the cases, this > company will never need an additional allocation and will > therefore only need to announce one route entry? That does > conserve a dimension in tension. We have already covered the idea of using /32 for any and all RIR allocations. It's not politically viable, and there were some technical concerns raised. Go back and read the /48 vs /32 thread. There wasn't a single post in support of using /32 for non-ISP allocations. > God help us if we start to hand out /44's and then 5 years > from now someone creates an IPv6 application that results in > large numbers of /48 assignments, causing all the /44 allocations > to run out and get a second one. Then, when we see the problem > and adjust that /44 boundary up to /32, these organizations will > once again overflow their 2nd /44 and get a 3rd /32 allocation. > And then we realize that it is virtually impossible to renumber > this application because it involves IPv6 addresses configured > into hardware devices that have no central management capability. > So now we have consumed 3 times as many global routing table entries > as we would have by BEING CONSERVATIVE AND GIVING EVERYONE A /32! This is easially solved by using a sparse allocation method that reserves a /32 around each /44, just in case the orgainization changes from an incidental aggregator to a primary aggregator. - Kevin From dr at cluenet.de Fri Apr 22 12:48:47 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 22 Apr 2005 18:48:47 +0200 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: <426907A9.4020208@hotnic.net> Message-ID: <20050422164847.GA10205@srv01.cluenet.de> On Fri, Apr 22, 2005 at 04:11:09PM +0100, Michael.Dillon at radianz.com wrote: > If a company receives an AS number then they can announce > any number of prefixes into the global routing table. Why not > give them a /32 knowing that in 99% of the cases, this > company will never need an additional allocation and will > therefore only need to announce one route entry? That does > conserve a dimension in tension. > > God help us if we start to hand out /44's and then 5 years > from now someone creates an IPv6 application that results in > large numbers of /48 assignments, causing all the /44 allocations > to run out and get a second one. Then, when we see the problem > and adjust that /44 boundary up to /32, these organizations will > once again overflow their 2nd /44 and get a 3rd /32 allocation. We're talking of PI space, not LIR PA space. So a PI owner is never supposed to assign subnets from his own PI space to customers (I know there are grey areas). The only thing that you achieve with handing out /32 PI is that people don't become LIR anymore, but just buy/get PI and assign /48s to customers ("screw documentation!"). By limiting PI to /48 (or larger for real documented need) you take away this incentive to avoid becoming LIR (ARIN member) as customers of such "PI ISPs" would be able to get only sub-standard sized blocks. PI is for multihomed sites, not ISPs assigning /48s down to customers, and as such the same rules as for end users assignments (which PI essentially is) should apply. > I'd like to point out that my IPv4 DSL provider gives me a /32 > for my home DSL connection and they never even asked whether > or not I had a router or a single PC. If this is justification > enough to get one 4.3 billionth of the IPv4 address space, then > why does a company need to go through contortions to justify > one 4.3 billionth of the IPv6 address space? Because a v4 /32 is the absolute minimum sized assignment possible, and a v6 /32 is about 4.3 billion times of that. Over-conservation is bad. Throwing around with space like there's no tomorrow is as well. Look at techniques like embedded RP in IPv6 multicast for a clue why. One unnecessarily endangers the option to use such techniques by wasting address space. Really. A /48 is 16 bit CIDRing(!) space. That's enough for almost everyone in the forseeable future. If you can justify more (huge amounts of subnets, large and diverse internal routing hierarchy crying for more flexibility in subnetting) you can always get more, IF justified. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Fred.Wettling at bechtel.com Fri Apr 22 13:20:59 2005 From: Fred.Wettling at bechtel.com (Wettling, Fred) Date: Fri, 22 Apr 2005 13:20:59 -0400 Subject: [ppml] 2005-1:Multinational Business Enablement Message-ID: <3400197AD5EC0540BC920AB9A1FD24330190EE3E@fres0094.amers.ibechtel.com> ARIN Policy Proposal 2005-1 removes one of the current obstacles for the real-world deployment of IPv6 by multi-national businesses. Global enterprise address management is critical. Global businesses are also challenged with unique routing policy and multi-homed sites which are the criteria for assignment of an AS Numbers (ARIN Policy Section 5). Beyond multi-homing at multiple sites, businesses also concurrently deal with dozens of service providers around the planet in the deployment of IP-based enterprise WAN backbones. Proposal 2005-1 is solid and helps businesses in the effective planning, deployment, and management global enterprise IPv6 address spaces based on the established and well understood Autonomous System Number Guidelines. I encourage the Proposal 2005-1 comments to focus on how the adoption of IPv6 can be ENABLED for businesses with minimum complexity. Current standards and policies do not adequately address unique routing, multi-homing, and multiple service providers on a global basis. Fred Wettling Bechtel Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From patara at lacnic.net Fri Apr 22 13:24:43 2005 From: patara at lacnic.net (Ricardo Patara) Date: Fri, 22 Apr 2005 14:24:43 -0300 Subject: [ppml] ARIN Certificates In-Reply-To: References: <6.0.1.1.2.20050421063020.03cded80@localhost> <16998.48927.155536.313492@roam.psg.com> <20050420205639.GA24586@srv01.cluenet.de> <1114066789.9920.5.camel@firenze.zurich.ibm.com> Message-ID: <20050422172443.GD95421@lacnic.net> hello, Just a small observations | >* LACNIC uses a, it seems to be, modified ARIN server, thus no CIDR | > support either. LACNIC whois interface does support CIDR notation. | As far as I know LACNIC runs modified version of RIPE server - older version | with additional custom support added for org data. They could possibly even | move to regular current ripe server (as new ripe server now supports orgs), | but I don't know if that is planned or not. well, the output format is some how similar to old rpsl representation. But the server is not a modified version of RIPE. It has only similar output. Ricardo, From andrew.dul at quark.net Fri Apr 22 14:43:49 2005 From: andrew.dul at quark.net (Andrew Dul) Date: Fri, 22 Apr 2005 18:43:49 +0000 Subject: [ppml] v6 PI space and Edu Message-ID: <20050422184349.5010.qmail@hoster908.com> -------Original Message------- > From: "Owen DeLong" > Subject: Re: [ppml] v6 PI space and Edu > Sent: 21 Apr 2005 22:28:30 > > Fictional example: > > We, Ferndale Underwater Controlled Kinetics University, propose to provide > a V6 /48 to each of our 200 dorm rooms as well as IP services for the > various departments, libraries, and administrative, and infrastructure > facilities on the campus. As such, we wish to become an LIR. Given > that we have 200 dorm rooms each of which is a customer, we believe > that we qualify under the IPv6 policies for a direct ARIN allocation > to us as an LIR. > > Guess what... The above complies with the policy and they would be able > to do it. Do you really think that there is a university that can't come > up with a plan for 200 downstream "customers" if they can count all their > departments, admin, campus health, etc. and, if they provide IP services > to students in their dorms, those count too? > > I think current policy more than adequately meets the needs of most colleges > and universities. Discussions with ARIN staff after my posting confirmed your interpretation that most universities would qualify for a v6 /32 as an LIR. Andrew From jeroen at unfix.org Fri Apr 22 14:43:03 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Apr 2005 20:43:03 +0200 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> Message-ID: <1114195383.5691.66.camel@firenze.zurich.ibm.com> On Fri, 2005-04-22 at 09:25 -0400, Wettling, Fred wrote: > ARIN Policy Proposal 2005-1 removes one of the current obstacles for the > real-world deployment of IPv6 by multi-national businesses. Global > enterprise address management is critical. Global businesses are also > challenged with unique routing policy and multi-homed sites which are the > criteria for assignment of an AS Numbers (ARIN Policy Section 5). Beyond > multi-homing at multiple sites, businesses also concurrently deal with > dozens of service providers around the planet in the deployment of IP-based > enterprise WAN backbones. Let's make a nice normal typical example of a 'multi-national business': Thus there is a company lets name it Example Corp. This company has offices (read: sites) all around the world (New York, Amsterdam, Paris, London, Tokyo, Canberra, Seoul, Lima, etc). Every site has their own admins so they want a /48 per site, just like every enduser with a dsl line, cellphone, or whatever connectivity method gets a /48. As this company is large it also has a lot of employees, and these like to dial in to the company network using VPN's. Thus everytime a employee connects, this employees network wants to get connected to the company network and thus the VPN gets a /48 routed over it too. Effectively this company will thus need a /32 or similar large sized block, just like Google and Microsoft amongst others already have. Now a fun part. The site in Lima doesn't have that much connectivity, it has only a 2mbit SAT uplink. The site in Paris is also not very well connected, only a 10mbit leased line. The webservers need a 1Gbit connection, because a lot of French people are connecting to it etc. Those webservers are located in New York. Now where are you going to do your BGP announcements? Do remind that the company gets a single /32 and are not supposed to be announcing multiple /48's out of that, as that will break the whole idea of aggregation. Also keep in mind that if you only announce it in New York that traffic from the employees summer house in Nice will flow over New York to Paris, introducing a nice 160ms latency for his SSH connection. If you announce it in Paris, without limiting it to the peers, because then you introduce the latency again, then a lot of french people and surrounding areas will go over that teeny 10mbit leased line, while they all might want to download that super cool new product advertisement movie, which does fit over the 1Gbit pipe at the webservers but does not fit over the 10mbit leased line... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From L.Howard at stanleyassociates.com Fri Apr 22 15:10:22 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 22 Apr 2005 15:10:22 -0400 Subject: [ppml] ARIN Certificates Message-ID: > i don't think that i, for one, will be inclined to agree to > having any rir, nro, ... revoke my cert for any reason other > than my specifically requesting it in an extremely well > authenticated manner. > > "dear customer: we can no longer announce your prefix because > apnic has revoked our certificate due to a billing problem and > our bgp neighbors will no longer accept our sbgp announcements. > of course, you may not get this email, so what the heck." > > not a chance in hell. a cert is your certifying my identity, > not my membership or billing status. A good point, although for some value of "reclamation" as defined through the public policy process, I could imagine this being useful. Under current practice, address space is not "reclaimed" because of overdue billing; I don't imagine the public would support changing that. But if ARIN believes you are not you (i.e., fraud/hijacking has been committed), then they could "reclaim" the space, with an intent consistent with the cert. > randy Lee From kloch at hotnic.net Fri Apr 22 15:46:40 2005 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 22 Apr 2005 15:46:40 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <20050422164847.GA10205@srv01.cluenet.de> References: <426907A9.4020208@hotnic.net> <20050422164847.GA10205@srv01.cluenet.de> Message-ID: <426954A0.7040008@hotnic.net> Daniel Roesen wrote: > We're talking of PI space, not LIR PA space. So a PI owner is never > supposed to assign subnets from his own PI space to customers (I > know there are grey areas). The /44's I was referring to would be an LIR allocation with the same responsibility for reassignment, record keeping and aggregation as a full size LIR with a /32. The difference is these "mini-LIR's" would provide transit as an side effect of running their business as opposed to an ISP LIR whose transit business is their primary substantial activity. Because most "multihoming" type organizations would easially be able to justify a handful of /48 reassignments, this is a useful metric for deciding if they have enough "stuff" for a routing slot. There are enough variables in play to allow fine tuning similar to the way IPv4 policy has been adjusted over time. Throw in a multihoming requirement and it's really not much different than the current IPv4 policy. If you are multihomed you have to justify less "stuff" than if you are aren't. - Kevin From owen at delong.com Sat Apr 23 03:15:02 2005 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Apr 2005 00:15:02 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: <5D8BA47E1917767BC39BD58D@[192.159.10.101]> > I'd like to point out that my IPv4 DSL provider gives me a /32 > for my home DSL connection and they never even asked whether > or not I had a router or a single PC. If this is justification > enough to get one 4.3 billionth of the IPv4 address space, then > why does a company need to go through contortions to justify > one 4.3 billionth of the IPv6 address space? Michael, Resources are not allocated based on the fraction of total available resources they represent. They are allocated based on need. By your proposal, the bigger the storage tank at a given gasoline station, the less you should pay per liter for the gas. Afterall, a bigger tank means that more liters si the same portion of the available gas compared to the station with the smaller holding tank. 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 Sat Apr 23 03:19:24 2005 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Apr 2005 00:19:24 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <20050422164847.GA10205@srv01.cluenet.de> References: <426907A9.4020208@hotnic.net> <20050422164847.GA10205@srv01.cluenet.de> Message-ID: <1A9C15877DFCC4F4414F1693@[192.159.10.101]> > > Because a v4 /32 is the absolute minimum sized assignment possible, > and a v6 /32 is about 4.3 billion times of that. A v4 /32 is 2^0 addresses. A v6 /32 is 2^96 addresses. 4.3 billion is approximately 2^32, so, it is actually about 4.3^3 times that. 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 Sat Apr 23 03:28:41 2005 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Apr 2005 00:28:41 -0700 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: <1114195383.5691.66.camel@firenze.zurich.ibm.com> References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> Message-ID: > Let's make a nice normal typical example of a 'multi-national business': > > Thus there is a company lets name it Example Corp. > This company has offices (read: sites) all around the world (New York, > Amsterdam, Paris, London, Tokyo, Canberra, Seoul, Lima, etc). Every site > has their own admins so they want a /48 per site, just like every > enduser with a dsl line, cellphone, or whatever connectivity method gets > a /48. As this company is large it also has a lot of employees, and > these like to dial in to the company network using VPN's. Thus everytime > a employee connects, this employees network wants to get connected to > the company network and thus the VPN gets a /48 routed over it too. > Um... generally, the company should be giving /64s to the employees, VPNs, etc., not /48s. Every end user with a DSL line, generally, should also be getting a /64 unless they have need of multiple networks, in which case, a /48 would be justified. > Effectively this company will thus need a /32 or similar large sized > block, just like Google and Microsoft amongst others already have. > Not necessarily, however, this example is _NOT_ the example that 2005-1 is targeted for. This example could be an LIR. Now, if the company wants to treat each site as a separate ORG, then, those sites might, individually be eligible for /48s under 2005-1. > Now a fun part. The site in Lima doesn't have that much connectivity, it > has only a 2mbit SAT uplink. The site in Paris is also not very well > connected, only a 10mbit leased line. > > The webservers need a 1Gbit connection, because a lot of French people > are connecting to it etc. Those webservers are located in New York. > > Now where are you going to do your BGP announcements? > > Do remind that the company gets a single /32 and are not supposed to be > announcing multiple /48's out of that, as that will break the whole idea > of aggregation. Also keep in mind that if you only announce it in New > York that traffic from the employees summer house in Nice will flow over > New York to Paris, introducing a nice 160ms latency for his SSH > connection. If you announce it in Paris, without limiting it to the > peers, because then you introduce the latency again, then a lot of > french people and surrounding areas will go over that teeny 10mbit > leased line, while they all might want to download that super cool new > product advertisement movie, which does fit over the 1Gbit pipe at the > webservers but does not fit over the 10mbit leased line... > If you're going to be an LIR, it comes with the responsibility for building a backbone sufficient to meet your Intradomain connectivity needs. If your dealing with multiple organizations that are diversly connected, then, topologically they are many small organizations, not one large one. 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 lea.roberts at stanford.edu Sat Apr 23 10:35:01 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sat, 23 Apr 2005 07:35:01 -0700 (PDT) Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: Message-ID: Owen (et al) - for DSL users, ARIN's NRPM section 6.9, channeling RFC3177, says: "In particular, we recommend: o Home network subscribers, connecting through on demand or always on connections should receive a /48." so the DSL assertion is within current policy... though I agree it seems somewhat wasteful. I suspect the basis is as assumption that multiple subnet homes will become the norm. note that the IPv6 round table on Wednesday included some presentations and lively discussion regarding whether it's time to revise the reassignment part of the IPv6 policy to include at least a /56 if not a /60 as recommendations. Geoff Huston has produced some calculations that show using the current policy would potentially consume a substantial fraction of the IPv6 address space within 60 years. Adding /56 for reassignments, e.g. for home DSL connections, would provide a 2 orders of magnitude cushion. but that's for a separate discussion.... more on that later! /Lea On Sat, 23 Apr 2005, Owen DeLong wrote: > > Let's make a nice normal typical example of a 'multi-national business': > > > > Thus there is a company lets name it Example Corp. > > This company has offices (read: sites) all around the world (New York, > > Amsterdam, Paris, London, Tokyo, Canberra, Seoul, Lima, etc). Every site > > has their own admins so they want a /48 per site, just like every > > enduser with a dsl line, cellphone, or whatever connectivity method gets > > a /48. As this company is large it also has a lot of employees, and > > these like to dial in to the company network using VPN's. Thus everytime > > a employee connects, this employees network wants to get connected to > > the company network and thus the VPN gets a /48 routed over it too. > > > Um... generally, the company should be giving /64s to the employees, VPNs, > etc., not /48s. Every end user with a DSL line, generally, should also be > getting a /64 unless they have need of multiple networks, in which case, > a /48 would be justified. > From dr at cluenet.de Sat Apr 23 07:42:45 2005 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 23 Apr 2005 13:42:45 +0200 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <1A9C15877DFCC4F4414F1693@[192.159.10.101]> References: <426907A9.4020208@hotnic.net> <20050422164847.GA10205@srv01.cluenet.de> <1A9C15877DFCC4F4414F1693@[192.159.10.101]> Message-ID: <20050423114245.GA19642@srv01.cluenet.de> On Sat, Apr 23, 2005 at 12:19:24AM -0700, Owen DeLong wrote: > > Because a v4 /32 is the absolute minimum sized assignment possible, > > and a v6 /32 is about 4.3 billion times of that. > > A v4 /32 is 2^0 addresses. A v6 /32 is 2^96 addresses. 4.3 billion > is approximately 2^32, so, it is actually about 4.3^3 times that. My "about 4.3 billion times of that." was meant as "about 4.3 billion times of the minimum possible assignment size (/48)". I'm equalling v4/32 to v6/64 in that. I'm not comparing addresses, but relative sizes of minimum routable assignments. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Sat Apr 23 07:46:15 2005 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 23 Apr 2005 13:46:15 +0200 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> Message-ID: <20050423114615.GB19642@srv01.cluenet.de> On Sat, Apr 23, 2005 at 12:28:41AM -0700, Owen DeLong wrote: > Um... generally, the company should be giving /64s to the employees, VPNs, > etc., not /48s. Every end user with a DSL line, generally, should also be > getting a /64 unless they have need of multiple networks, in which case, > a /48 would be justified. Nope. They should get a /48 unless they can convincingly show that they'll never need more than a single subnet. > If you're going to be an LIR, it comes with the responsibility for > building a backbone sufficient to meet your Intradomain connectivity > needs. Can you show me the policy where this is outlined? I don't know any RIR IP addressing or membership policy which suggests any responsibilities in regard of routing matters. > If your dealing with multiple organizations that are diversly > connected, then, topologically they are many small organizations, > not one large one. Routing-wise yes. Organizationally most often not. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From owen at delong.com Sat Apr 23 16:18:03 2005 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Apr 2005 13:18:03 -0700 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: <20050423114615.GB19642@srv01.cluenet.de> References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel .com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> Message-ID: <50209E6DFA08D3CE9908756D@imac-en0.delong.sj.ca.us> >> If you're going to be an LIR, it comes with the responsibility for >> building a backbone sufficient to meet your Intradomain connectivity >> needs. > > Can you show me the policy where this is outlined? I don't know any > RIR IP addressing or membership policy which suggests any > responsibilities in regard of routing matters. > Well... I suppose it's not explicitly stated in RIR policy, but, it is certainly implicit in the definition of an LIR: 2.4. Local Internet Registry (LIR) - A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs, whose customers are primarily end users and possibly other ISPs. If you are assigning address space to users of network services that you provide, than, isn't providing those network services inherent in that definition? >> If your dealing with multiple organizations that are diversly >> connected, then, topologically they are many small organizations, >> not one large one. > > Routing-wise yes. Organizationally most often not. > My point is that the IP Policy definition of an Organization tends to be more topologically aligned than financially. This is an unfortunately vague part of the policy (for example, the term organization is often used and never defined), but, lots of large companies (and even some smaller ones) comprise multiple organizations for IP allocation purposes. 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 lea.roberts at stanford.edu Sat Apr 23 16:46:26 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sat, 23 Apr 2005 13:46:26 -0700 (PDT) Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: <50209E6DFA08D3CE9908756D@imac-en0.delong.sj.ca.us> Message-ID: Owen - NOTE: this is only hearsay, perhaps I misunderstood. FYI, it was reported in Orlando by several large orgsnizations that they were denied IPv6 allocations by ARIN staff who interpreted that the 200 "other organizations" had to be financially separate, i.e. not receiving funding from the applicant orgsnization. NOTE: this is only hearsay, perhaps I misunderstood. (still sorry, Doug :-) in any case, it seems for large, multi-site organizations to qualify we need to continue to clarify the policy... /Lea On Sat, 23 Apr 2005, Owen DeLong wrote: > >> If you're going to be an LIR, it comes with the responsibility for > >> building a backbone sufficient to meet your Intradomain connectivity > >> needs. > > > > Can you show me the policy where this is outlined? I don't know any > > RIR IP addressing or membership policy which suggests any > > responsibilities in regard of routing matters. > > > Well... I suppose it's not explicitly stated in RIR policy, but, it is > certainly implicit in the definition of an LIR: > > 2.4. Local Internet Registry (LIR) - A Local Internet Registry (LIR) is an > IR that primarily assigns address space to the users of the network > services that it provides. LIRs are generally ISPs, whose customers are > primarily end users and possibly other ISPs. > > If you are assigning address space to users of network services that you > provide, than, isn't providing those network services inherent in that > definition? > > >> If your dealing with multiple organizations that are diversly > >> connected, then, topologically they are many small organizations, > >> not one large one. > > > > Routing-wise yes. Organizationally most often not. > > > My point is that the IP Policy definition of an Organization tends to be > more topologically aligned than financially. This is an unfortunately > vague part of the policy (for example, the term organization is often > used and never defined), but, lots of large companies (and even some > smaller ones) comprise multiple organizations for IP allocation purposes. > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. > From stephen at sprunk.org Sun Apr 24 10:13:48 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 24 Apr 2005 09:13:48 -0500 Subject: [ppml] 2005-1:Multi-national Business Enablement References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> Message-ID: <025801c548d9$260aeb00$6601a8c0@stephen> Thus spake "Daniel Roesen" > On Sat, Apr 23, 2005 at 12:28:41AM -0700, Owen DeLong wrote: > > Um... generally, the company should be giving /64s to the > > employees, VPNs, etc., not /48s. Every end user with a DSL > > line, generally, should also be getting a /64 unless they have > > need of multiple networks, in which case, a /48 would be justified. > > Nope. They should get a /48 unless they can convincingly show that > they'll never need more than a single subnet. It is ridiculous to think that ISPs are going to completely discard their current IPv4 topology to deploy IPv6. Most "residential" ISPs I'm aware of use a single subnet for N customers, and that is perfectly reasonable to continue with IPv6 -- just assign a /64. That allows customers to put as many hosts as they want on the "bare" connection, and any who want their own subnet(s) can be issued a /64 or /48 of their own -- but most will not be interested in that or even understand what it means. For employee VPNs and such, the same model applies. Today, users get a /32; for IPv6, they would get a /128. Since corporate policies often _forbid_ having more than one PC at the other end of a VPN connection (each should have its own), it makes no sense to issue a shorter prefix. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From Michael.Dillon at radianz.com Mon Apr 25 06:41:52 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 25 Apr 2005 11:41:52 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <5D8BA47E1917767BC39BD58D@[192.159.10.101]> Message-ID: > Resources are not allocated based on the fraction of total available > resources they represent. They are allocated based on need. No they aren't. They are allocated based on the rules set down in policy. And when policies are written, they should take into consideration the amount of resources available and the impact on availability of a typical allocation. > By your > proposal, the bigger the storage tank at a given gasoline station, the > less you should pay per liter for the gas. Not at all. By analogy with petrol, the bigger the petroleum reserves that your policymaking organization (i.e country) has access to, the less you should pay per litre for petrol. Oh wonder, of wonders! When I look at the prices of petrol in Canada and in Russia, they are considerably cheaper than in the UK. Yes, I have spent some time in all 3 countries and personally witnessed the prices of petrol. This is economics, and in the world of IP addressing economics, it is a fact that the IPv6 reserves are vastly larger than the IPv4 reserves, and that the impact on those reserves of a /32 allocation is roughly identical. Therefore, the impact of allocating an IPv6 /32 to an ISP is roughly identical to the impact of allocating an IPv4 /32 host address to a single interface on a device. Once again, the lessons learned from IPv4 cannot be blindly applied to IPv6. We must carefully consider the meaning of those lessons in a rather different context. Russia and Canada would be foolish to allow the price of petrol to rise to the levels common in the UK because they must deal with completely different economic conditons. In the IPv6 world, we have a vastly larger address space than IPv4 and it is no exaggeration to say that none of us will live long enough to see this address space exhausted. In IPv6, the concept of allocating a single /48 to every stub network is quite different from the IPv4 concept of allocating variable size blocks based on need. It's a different address economy and it needs different rules and policies. --Michael Dillon From Michael.Dillon at radianz.com Mon Apr 25 06:46:20 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 25 Apr 2005 11:46:20 +0100 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: Message-ID: > o Home network subscribers, connecting through on demand or > always on connections should receive a /48." > > so the DSL assertion is within current policy... though I agree it seems > somewhat wasteful. Why is it wasteful? To begin with it is 1/256th of the amount of IPv4 addresses allocated to my DSL connection. A /48 is a lot smaller than a /32. > I suspect the basis is as assumption that multiple > subnet homes will become the norm. Indeed! --Michael Dillon From Ed.Lewis at neustar.biz Mon Apr 25 10:24:11 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 25 Apr 2005 10:24:11 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: At 16:11 +0100 4/22/05, Michael.Dillon at radianz.com wrote: >IPv6 is not IPv4. Being prudent and conservative in an IPv6 >world involves different behaviors than being conservative >in an IPv4 world. Reading the further discussions bring me back to this statement. I wonder what the differences are. I can think of some. When I hear arguments about fractions of space available, I don't see why fractions are relevant. More and more, IPv4 and IPv6 seem alike to me. IPv6 only adds bits to the address. IPv6 promises a new generation of software to make all sorts of other wonderful things happen - but as it's taken so long to get rolling, it is now plagued by the same disease as IPv4 - hardening of the software. E.g., renumbering IPv6 networks is impinged by firewall rules - firewalls weren't around back when IPv6 design work began. In addition, IPv4 has been accreting capability to come up to what was wanted from IPv6. (E.g., NAT has extended the address space.) A /32 of IPv4 space is the same percentage as a /32 of IPv6 space. That's obvious. So what? With more address space available, I would expect to get a smaller percentage of the overall space. The one alleged feature of IPv6 that plays to the size of the addresses and the amount assigned to a network is its "security through obscurity" achieved by being sparse. I find it ironic that folks will say that "because it takes so long to scan a network" the net is more secure yet also say that "NAT provides no security." Not that NAT provides security, but how is a wasting a lot of space to hide a server any better? The one pertinent difference is that devices are supposed to be capable of having multiple addresses on an interface - for multicast groups, etc. I can buy that you need to allocate more addresses than interfaces, something not widely done in IPv4. This is a double edged sword - scoped addressing isn't something generally beneficial to applications. (Do I open the SSH session over a globally unique address or the local scope address?) What I'm afraid I am hearing is that "since there are so many more IPv6 addresses, let's loosen the address supply to make it easier to manage." That sounds a little like a cop out, understanding that the technology is immature and we don't really know where it's heading. If you put a /48 in my house, with each device getting a /64 to assign a /128 to it's interfaces, I still have a hard time imagining that this would be an efficient use of space. Even with MIT-like smart kitchens, etc., I can't imagine that much address space being needed and used efficiently. (Especially for those who've been to my house. I could address all of the items in my fridge with a v4 /29, maybe a /28 after a trip to Giant.) It seems to me that IPv6 DHCP assigning addresses more compactly than using the Ethernet address as the last 48 bits would be worth the management overhead. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Michael.Dillon at radianz.com Mon Apr 25 11:31:42 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 25 Apr 2005 16:31:42 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: Message-ID: > A /32 of IPv4 space is the same percentage as a /32 of IPv6 space. > That's obvious. So what? With more address space available, I would > expect to get a smaller percentage of the overall space. You do! There are only a few ISPs, mostly in 3rd world countries, who have to make do with only a /32 of IPv4 space. Conversely, in IPv6, there are only a few ISPs who need more than a /32 of IPv6 space. > What I'm afraid I am hearing is that "since there are so many more > IPv6 addresses, let's loosen the address supply to make it easier to > manage." That sounds a little like a cop out, understanding that the > technology is immature and we don't really know where it's heading. Not at all. I am not suggesting that we "loosen" the address supply. The characteristics of IPv6 (larger address space, allocation of /48 to stub networks) have naturally resulted in a much tighter set of rules in which the majority of ISPs will receive only a /32 of space. This is much, much less than what we give ISPs from the IPv4 space. > If you put a /48 in my house, with each device getting a /64 to > assign a /128 to it's interfaces, I still have a hard time imagining > that this would be an efficient use of space. Now you are thinking like a Bedouin in the Sahara. When water is scarce and you must travel many days to reach a water source, then it seems like incredible waste to use water for washing. You have a hard time imagining that people anywhere could justify the use of water for washing their bodies. But in the interior of British Columbia, in a semi-desert area called the Okanagan Valley, people who live along the shores of a large freshwater lake fed by mountain glaciers have a rather different viewpoint. As do the residents of Seattle, where it is not unusual for the rain to fall for days without stopping. The question of waste has to do with the environment you are in, the sources of supply, and the difficulty of obtaining a resource. IPv6 addresses may be finite in number, like water molecules on this planet, but they are as numerous as the raindrops which fall on the western rainforests of North America. It would be inefficient for a resident of Seattle to live in a tent, ration himself to 5 liters of water per day for drinking and cooking and only wash himself in a public shower facility. Unless, of course, he is on a trip in the north Sahara. Similarly, it is inefficient for users of IPv6 addresses to try to design their networks to conserve addresses according to IPv4 rules. > Even with MIT-like > smart kitchens, etc., I can't imagine that much address space being > needed and used efficiently. No doubt most Bedouins cannot imagine why an American needs 5 gallons to flush the toilet. This is the daily water ration for 4 adults on trek in the north Sahara! > It seems to me that IPv6 DHCP assigning addresses more compactly than > using the Ethernet address as the last 48 bits would be worth the > management overhead. You are at liberty to run your home network the way that you want to but when we make IPv6 addressing policy we have to do it in the context of the IPv6 RFCs in which it is mandatory to assign a /48 to any stub network unless it needs more addresses. We can't change that. Our policies have to deal with allocations of blocks larger than /48 in size to network operators who then assign /48 out of their allocation. --Michael Dillon From Ed.Lewis at neustar.biz Mon Apr 25 11:55:34 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 25 Apr 2005 11:55:34 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: At 16:31 +0100 4/25/05, Michael.Dillon at radianz.com wrote: >> If you put a /48 in my house, with each device getting a /64 to >> assign a /128 to it's interfaces, I still have a hard time imagining >> that this would be an efficient use of space. > >Now you are thinking like a Bedouin in the Sahara. When water is scarce Analogies don't help me understand the problem any better. Yeah, scarcity is relative. Today I have 3 IP addresses DHCP assigned to me, and even that seems plenty - I've never used more than 2 at a time, 99.99% of the time I use just one. What will I be addressing that will need more addresses? >You are at liberty to run your home network the way that you want to I don't run my home network. As much as networking is my career, I leave it at the office. In my house I have a few client machines, no servers, probably even less sophisticated than what my parents have. I leave the network management to the ISP I buy service from. What I mean is - I have yet to be convinced that there is a concrete reason to assign gobs of addresses to my house. Why not dole out IPv6 a few addresses at a time until it's clear I need a /48 or /52 or /60. My lack of addresses (when I am home) isn't what's holding back innovation. Wouldn't my squandering addresses be a bigger risk to future innovation? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From bicknell at ufp.org Mon Apr 25 12:45:16 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 25 Apr 2005 12:45:16 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: <20050425164516.GA38607@ussenterprise.ufp.org> In a message written on Mon, Apr 25, 2005 at 04:31:42PM +0100, Michael.Dillon at radianz.com wrote: > The question of waste has to do with the environment you are in, the sources > of supply, and the difficulty of obtaining a resource. IPv6 addresses may Your analogy here holds more water than you might think. Water, like IPv6 addresses, is abundant. Drinkable water, like usable IPv6 addresses, is not. Using a /64 for a "LAN" is like dumping raw sewage into the water and then wondering why it's contaminated. 2^32 times more than the entire existing address space, for a single LAN. When you dump in pollution, you prevent those downstream from using the water to drink. Similarly, when you number a lan with a /64 you prevent other network users from using any of those addresses, even though you may only have 50,000 or 1,000,000 devices on your local LAN. Similarly, at the subnet level we have the same thing. A /48 is 2^16 bits of subnet, or 65536 subnets. Now, I'll be the first to admit I'd like to not have to use 1918 space for the 650 subnets I have at home behind my 3Mbps cable modem, but giving me 100 times that again prevents someone else from using the space who might actually need it. The problem with all of this is we're extremely bad predictors of the future. Back in the day, a /8 (16/8, to be specific) to DEC seemed like they right thing to do, their big, they will grow. Similarly, giving MCI a /24 (198.4.182.0/24 to be specific) in 1993 seemed like a smart idea, they were just a small dial up e-mail provider, after all. So, while the IPv6 authors are busing thinking about my 65000 subnets at home, and my 18 quintillion hosts per subnet they are forgetting that the most interesting things that happen in the future are the things we can't predict now. Much as people laughed at the concept that you would need a microprocessor in every doorknob in the 1960's, we now regularly use them on a day to day basis in hotels and businesses around the world. We have people who are talking about allocating IPv6 addresses to serve a 60 year need. Well, that's all well and good, but it's only 40 years after the doorknob quote and the reality is quite different. Ideas that seem far fetched today like colonizing mars, or faster than light travel, or nanomachines that have IP stacks may be so common place in 60 years time that no one gives them a second thought. What's most absurd about things like a /48 for cable modem users is that it only promotes waste. Having fixed addresses is great /but only if you can take them with you/. Well, if you can take them with you that's an entry in the global table, which is not what any of us want. So presumably, you won't take them with you, which means every time you move you'll be getting new IP's. How many people live in the same place for 60 years? Can't we use these external events to adjust the size of the blocks given out over time? While I may look like a stodgy conservative when it comes to address space management, I'l really not. I'm pretty much a give it away sort of guy....just on a sane scale. Let's give every home a /104 (that is, the same amount of address space that's in a /8 today). Further, let's go ahead and let them have 256 subnets, so it's a /96 per house. If I'm right that this is wanton waste, we just recovered a 48 BITS of address space. If I'm wrong, in 10 years we can start giving out /80's to home users, 65,000 times the address space, and still have recovered a full 32 bits of the address space. That way when my grandchildren colonize alpha centauri and have to number the six trillion whoiewhats that live there already they will have plenty of space. In other words, let's take a bath in the water, and enjoy that it is plentiful, but let's not dump raw sewage into the lake "because it doesn't matter". History has a way of always making it matter. -- 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 Ed.Lewis at neustar.biz Mon Apr 25 13:16:32 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 25 Apr 2005 13:16:32 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <20050425164516.GA38607@ussenterprise.ufp.org> References: <20050425164516.GA38607@ussenterprise.ufp.org> Message-ID: At 12:45 -0400 4/25/05, Leo Bicknell wrote: >things we can't predict now. Much as people laughed at the concept >that you would need a microprocessor in every doorknob in the 1960's, >we now regularly use them on a day to day basis in hotels and >businesses around the world. Folks laugh at "the world market is for 6 or so computers" and "640K ought to be enough." OTOH... >The problem with all of this is we're extremely bad predictors of >the future. Back in the day, a /8 (16/8, to be specific) to DEC As nothing more than an educated consumer, I would caution against waste "because of all that we could achieve with the excess." This is why I'm asking for what makes IPv6 address management different than IPv4. I don't see the difference, just analogies. Analogies are usually fine, I use them myself - but they are still hypothetical situations. Why, in say just 5 years, will I want more than a few addresses for my 30 year old house in a mature subdivision with only basic utilities and a phone plant incapable of DSL? (Or so I was told the last time I tried to get it.) If there is a good reason, then I wouldn't balk at getting a /64. Will more address space allow me to get higher bandwidth and better reliability? Will I be now able to have my own web servers in my house? My current provider won't even give me https access to my home mail unless I pay to become a small business. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owen at delong.com Mon Apr 25 14:48:13 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Apr 2005 11:48:13 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: <20050425164516.GA38607@ussenterprise.ufp.org> Message-ID: <2147483647.1114429693@delong-dhcp8.delong.sj.ca.us> I fear this discussion is drifting far afield from where it was intended to go. This is the ARIN PPML. We can't change the basic decisions made by the IETF here. We can only control ARIN resource policy. The decision to make every subnet a /64 and issue /48s or more to every end site (for a very strange definition of the term site) that requires more than one subnet was made in the IETF. If you want to change that, you need to get involved in the V6 Working Group. Policy 2005-1 is about trying to get provider independent allocations for organizations which would not otherwise qualify as LIRs. While, to some extent, the current rules were specified by the IETF, that is, in my opinion, more in the realm of policy than design. While the /48 and /64 decisions could be policy, given the current constraints and assertions in the V6 protocol specifications, it is not a policy decision, but, a design decision. Design is clearly in the realm of IETF. Policy has some overlap, but, I believe in the long run that the RIRs must be the ones with the majority of influence over policy. As such, let's focus here on what we can do within the realm of policy. Owen -------------- 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 Mon Apr 25 14:26:06 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Apr 2005 11:26:06 -0700 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: References: Message-ID: <2147483647.1114428365@delong-dhcp8.delong.sj.ca.us> --On Monday, April 25, 2005 11:46 +0100 Michael.Dillon at radianz.com wrote: >> o Home network subscribers, connecting through on demand or >> always on connections should receive a /48." >> >> so the DSL assertion is within current policy... though I agree it > seems >> somewhat wasteful. > > Why is it wasteful? To begin with it is 1/256th of the amount of IPv4 > addresses allocated to my DSL connection. A /48 is a lot smaller than > a /32. > No... A V6 /48 is smaller than a V6 /32, but, as you have pointed out, blindly mapping between V4 and V6 doesn't work. It is not 1/256th of your current V4, it isn't even 1/256th of a V6 /32 (it is 1/65,536th of a V6 /32), but, it is 2^79 times the size of your V4 /32. Do you really think that you need 2^79 times as much address space as you currently use? >> I suspect the basis is as assumption that multiple >> subnet homes will become the norm. > > Indeed! > I think multiple subnet homes will become more common. I already have one. I would oppose any policy that didn't allow a home user to obtain a /48 based on the desire to subnet. However, I don't think that is the same as saying every home user should automatically receive a /48. Today, there are home users that receive /32s and home users that receive larger assignments. In the IPv6 world, those same two groups fit perfectly well into /64 and /48, respectively. Admittedly, I have trouble picturing a home user needing more than 65,536 subnets, so, I don't see more than a /48 really being needed. 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 bicknell at ufp.org Mon Apr 25 15:09:13 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 25 Apr 2005 15:09:13 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <2147483647.1114429693@delong-dhcp8.delong.sj.ca.us> References: <20050425164516.GA38607@ussenterprise.ufp.org> <2147483647.1114429693@delong-dhcp8.delong.sj.ca.us> Message-ID: <20050425190913.GA45127@ussenterprise.ufp.org> In a message written on Mon, Apr 25, 2005 at 11:48:13AM -0700, Owen DeLong wrote: > While the /48 and /64 decisions could be policy, given the current > constraints > and assertions in the V6 protocol specifications, it is not a policy > decision, The /64 is a design decision consequence of RFC 2462. However, the /48 boudary is a recomendation in every draft I can find. Indeed, RFC 3177, the most on point here, starts right off with "this document provides recommendations to the addressing registries", and then proceeds to defend those recommendations. RFC's 3513 and RFC 3587 don't make any further requirements. So, while it may take the IETF to fix the /64 mess, the /48 mess can be fixed in RIR policy, including steps like moving it to a /56 or if you were so inclined a /44. If someone can point to where the IETF _requires_ a /48, I'm all ears as I've looked and can only find recomendations. -- 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 Ed.Lewis at neustar.biz Mon Apr 25 15:12:39 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 25 Apr 2005 15:12:39 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <2147483647.1114429693@delong-dhcp8.delong.sj.ca.us> References: <20050425164516.GA38607@ussenterprise.ufp.org> <2147483647.1114429693@delong-dhcp8.delong.sj.ca.us> Message-ID: At 11:48 -0700 4/25/05, Owen DeLong wrote: >I fear this discussion is drifting far afield from where it was intended >to go. > >This is the ARIN PPML. We can't change the basic decisions made by the IETF >here. We can only control ARIN resource policy. Right - but to make informed decisions about policy, there is a need to understand the ramifications. >The decision to make every subnet a /64 and issue /48s or more to every >end site (for a very strange definition of the term site) that requires >more than one subnet was made in the IETF. If you want to change that, >you need to get involved in the V6 Working Group. I don't want to change it. I want to know why the decisions made in the IETF are driving the policy here. Color me skeptical. >Policy 2005-1 is about trying to get provider independent allocations for >organizations which would not otherwise qualify as LIRs. While, to some >extent, the current rules were specified by the IETF, that is, in my >opinion, more in the realm of policy than design. We have "PI space" in IPv4. Why not have it in IPv6? That is, if there is no difference between IPv4 and IPv6 when it comes to resource management. But then I hear that v4 and v6 are vastly different. How so? Should we take a hard line and prevent "PI space" in IPv6 to force correctness? >While the /48 and /64 decisions could be policy, given the current constraints >and assertions in the V6 protocol specifications, it is not a policy decision, >but, a design decision. Design is clearly in the realm of IETF. Policy has >some overlap, but, I believe in the long run that the RIRs must be the ones >with the majority of influence over policy. 2005-1 is a policy, and that is in the subject of the message. Is it a good idea or not? That is a policy question. >As such, let's focus here on what we can do within the realm of policy. The IETF focuses on design, not on education. PPML focuses on policy, not on education. Where should people go to get educated on the design to offer informed opinions on policy? If the PPML is not for education, is it for "stumping"? How do we reach consensus if there is no arena in which to hear and consider differing opinions and viewpoints. > >Owen > > >Attachment converted: Macintosh HD:Untitled 828 ( / ) (0009C06F) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owen at delong.com Mon Apr 25 15:38:03 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Apr 2005 12:38:03 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: <20050425164516.GA38607@ussenterprise.ufp.org> <2147483647.1114429693@delong-dhcp8.delong.sj.ca.us> Message-ID: <2147483647.1114432682@delong-dhcp8.delong.sj.ca.us> >> The decision to make every subnet a /64 and issue /48s or more to every >> end site (for a very strange definition of the term site) that requires >> more than one subnet was made in the IETF. If you want to change that, >> you need to get involved in the V6 Working Group. > > I don't want to change it. I want to know why the decisions made in the > IETF are driving the policy here. Color me skeptical. > Uh, because the IETF is the body that makes design decisions for internet protocols, and, policy must, at some level, reflect those decisions. >> Policy 2005-1 is about trying to get provider independent allocations for >> organizations which would not otherwise qualify as LIRs. While, to some >> extent, the current rules were specified by the IETF, that is, in my >> opinion, more in the realm of policy than design. > > We have "PI space" in IPv4. Why not have it in IPv6? That is, if there > is no difference between IPv4 and IPv6 when it comes to resource > management. > > But then I hear that v4 and v6 are vastly different. How so? Should we > take a hard line and prevent "PI space" in IPv6 to force correctness? > Vastly different is one very vocal person's viewpoint. The reality, in my opinion (and I think the majority of those present) is that there is not a lot of difference other than the size of the pool. There are those that believe a hard line to prevent PI space is necessary because they fear that if we do not take said hard line, we will again face the problems which led originally to the CIDR hack, and, which provided some of the impetus for the NAT hack. Frankly, I think that it is appalling that v6 has come full circle. There were, originally, two proposals for v6. I forget the original name of the one which was pursued, but, the one which lost early on was called TUBA (Tcp/Udp with Big Addresses). The reason TUBA was discarded early on was because of belief that we needed to do a better job of addressing a number of issues and not simply create a protocol with bigger addresses. The issues that were deemed so critical were: + Autoconfiguration + Easy Renumbering + Mobile Computing + Security Of everything on this list, the current V6 proposal is marginally better in terms of security, and, fails to in any way provide an advantage over IPv4 in any of the other areas. Worse, V6 has no PI, while V4 has PI space readily available. This makes it a no-brainer to not adopt V6. Now V6 is proposaing ULA. ULA is like PI, but, you're not supposed to route it, nudge nudge, wink wink, and, you don't need to register it in any central database. >> While the /48 and /64 decisions could be policy, given the current >> constraints and assertions in the V6 protocol specifications, it is not >> a policy decision, but, a design decision. Design is clearly in the >> realm of IETF. Policy has some overlap, but, I believe in the long run >> that the RIRs must be the ones with the majority of influence over >> policy. > > 2005-1 is a policy, and that is in the subject of the message. Is it a > good idea or not? That is a policy question. > Well... I feel that the /48, /64, etc. discussion has wandered far afield from the topic of the 2005-1 policy proposal (whether or not to issue PI space to end users of V6 that can justify it). I just don't see how a debate of minimum prefix sizes overall for V6 is part of this discussion. >> As such, let's focus here on what we can do within the realm of policy. > > The IETF focuses on design, not on education. PPML focuses on policy, > not on education. Where should people go to get educated on the design > to offer informed opinions on policy? If the PPML is not for education, > is it for "stumping"? How do we reach consensus if there is no arena in > which to hear and consider differing opinions and viewpoints. > Start by reading the RFCs. Then, there's the IETF Mailing List archives. I'm not saying that PPML is not for hearing and considering different opinions or viewpoints. If you want to debate prefix sizes on PPML, I don't have any problem with that. Either find, or, propose a policy that deals with that issue, and, have that discussion within that thread. I'm just saying that it isn't what 2005-1 is about. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From david.conrad at nominum.com Mon Apr 25 15:42:29 2005 From: david.conrad at nominum.com (David Conrad) Date: Mon, 25 Apr 2005 12:42:29 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: Michael, On Apr 25, 2005, at 8:31 AM, Michael.Dillon at radianz.com wrote: > IPv6 addresses may > be finite in number, like water molecules on this planet, but they are > as numerous as the raindrops which fall on the western rainforests of > North America. Under current allocation policies there is a theoretical maximum 281,474,976,710,656 "allocatable units" and there can a be a theoretical maximum of 4,294,967,296 "ISPs", each of which having a theoretical maximum of 65,536 allocatable units. As we have seen with IPv4, 2^32 can be quite limiting if care isn't taken. Of course, there have already been quite a few allocations shorter than /32; the shortest in the APNIC and RIPE databases appears to be a /19 (I find this somewhat ... ironic given the initial allocations made when RIPE-NCC was set up was a /19...). > You are at liberty to run your home network the way that you want to > but when we make IPv6 addressing policy we have to do it in the context > of the IPv6 RFCs in which it is mandatory to assign a /48 to any > stub network unless it needs more addresses. We can't change that. Can't we? Rgds, -drc From Ed.Lewis at neustar.biz Mon Apr 25 16:24:56 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 25 Apr 2005 16:24:56 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <2147483647.1114432682@delong-dhcp8.delong.sj.ca.us> References: <20050425164516.GA38607@ussenterprise.ufp.org> <2147483647.1114429693@delong-dhcp8.delong.sj.ca.us> <2147483647.1114432682@delong-dhcp8.delong.sj.ca.us> Message-ID: At 12:38 -0700 4/25/05, Owen DeLong wrote: >Uh, because the IETF is the body that makes design decisions for internet >protocols, and, policy must, at some level, reflect those decisions. "Must?" The public (of public policy) is not beholden to the IETF. >Vastly different is one very vocal person's viewpoint. The reality, in >my opinion (and I think the majority of those present) is that there is >not a lot of difference other than the size of the pool. Just because a person is very vocal and not in the alleged majority doesn't mean that claims ought to be written off. I am asking about the differences because I don't see them (i.e., I agree with you) and because there does seem to be some smoke when we talk about v6 address allocation. >Well... I feel that the /48, /64, etc. discussion has wandered far afield >from the topic of the 2005-1 policy proposal (whether or not to issue PI >space to end users of V6 that can justify it). I just don't see how a debate >of minimum prefix sizes overall for V6 is part of this discussion. In the search for why v6 and v4 are different...and whether there may be another route to achieving the objective of the policy. >Start by reading the RFCs. Then, there's the IETF Mailing List archives. LOL, a good one. Seriously, have you ever tried to do that? Mail lists are really poor when it comes to researching ideas. Some archives just aren't available (DNSSEC WG). A lot of them reference internet-drafts that the IETF doesn't archive. In some active groups, I have been asked and failed to find justifications for a requirement that a draft author/editor popped into a document. The IETF isn't a place to learn... >I'm not saying that PPML is not for hearing and considering different opinions >or viewpoints. If you want to debate prefix sizes on PPML, I don't have >any problem with that. Either find, or, propose a policy that deals with >that issue, and, have that discussion within that thread. I'm just saying >that it isn't what 2005-1 is about. You can always kill the thread when you mind is made up on a topic. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From lea.roberts at stanford.edu Mon Apr 25 16:37:01 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 25 Apr 2005 13:37:01 -0700 (PDT) Subject: [ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments] In-Reply-To: <20050425190913.GA45127@ussenterprise.ufp.org> Message-ID: Leo (et al) - I really agree with you on this. Let's start a different thread (hence the subject change... :-) so the 2005-1 thread can maintain focus on the PI question. BTW, I believe that non-PI addresses are part of the same set of recommendations and so it is time to start defining the policy for what a reasonable set of constraints to allow PI assignments should be. The presentations during the IPv6 roundtable on Wednesday morning made a convincing case for revisiting the /48 gospel. For those of you who were not there, check out the first set of slides "Where did all those IPv6 addresses go? David Conrad channeling Geoff Huston" on the ARIN web site. By continuing to pass out /48s like candy, we can dig ourselves a real big hole! Granted, I won't be around to suffer, but Bill Darte spoke eloquently about the legacy we leave behind. Given the pain of changing the network that we are already experiencing, pretending addresses are an infinte resource seems very foolish. Sure the numbers are huge, but as so many others have pointed out, it's really hard to predict the future. If we don't ruin it, IPv6 can live for a long time and perhaps deliver on some of the yet-to-be-real design goals (e.g. renumbering can be much easier if the needed tools for DNS and ACLs are built... ;-) In any case, I find it easy to say that instead of assigning a /48 to home uesers, instead assigning a /56 to home users is an easy way for being less wasteful with being overly restrictive. If someone has a big enough home to need more than 200 subnets, then they can have their /48, but your "normal" home user couldn't possibly be overly constrained by that assignment. One of the comments during the discussion of the IPv6 roundtable pointed out that the /64 is also likely to be too little for the cell phones of the future which may well be the mobile router for your car network... :-0 so maybe cell phones will start getting /60s instead of /64s. In any case, let's try to get away from the belief that there are so many addresses we don't have to even think about address consumption and let the pendulum swing a little bit back toward the center. /Lea On Mon, 25 Apr 2005, Leo Bicknell wrote: > In a message written on Mon, Apr 25, 2005 at 11:48:13AM -0700, Owen DeLong wrote: > > While the /48 and /64 decisions could be policy, given the current > > constraints > > and assertions in the V6 protocol specifications, it is not a policy > > decision, > > The /64 is a design decision consequence of RFC 2462. However, the > /48 boudary is a recomendation in every draft I can find. Indeed, > RFC 3177, the most on point here, starts right off with "this > document provides recommendations to the addressing registries", > and then proceeds to defend those recommendations. RFC's 3513 and > RFC 3587 don't make any further requirements. > > So, while it may take the IETF to fix the /64 mess, the /48 mess > can be fixed in RIR policy, including steps like moving it to a /56 > or if you were so inclined a /44. > > If someone can point to where the IETF _requires_ a /48, I'm all > ears as I've looked and can only find recomendations. > > -- > 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 > From randy at psg.com Mon Apr 25 16:44:03 2005 From: randy at psg.com (Randy Bush) Date: Mon, 25 Apr 2005 10:44:03 -1000 Subject: [ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments] References: <20050425190913.GA45127@ussenterprise.ufp.org> Message-ID: <17005.22163.782435.233847@roam.psg.com> just to throw in a serious bomb, there is no actual real technical reason for the /64 magic boundary. it's one of the last big pieces of the old v6 religion. but beware that it does have some ties to ether-like mac addresses and hence auto-numbering. randy From william at elan.net Mon Apr 25 17:08:29 2005 From: william at elan.net (william(at)elan.net) Date: Mon, 25 Apr 2005 14:08:29 -0700 (PDT) Subject: [ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments] In-Reply-To: <17005.22163.782435.233847@roam.psg.com> References: <20050425190913.GA45127@ussenterprise.ufp.org> <17005.22163.782435.233847@roam.psg.com> Message-ID: On Mon, 25 Apr 2005, Randy Bush wrote: > just to throw in a serious bomb, there is no actual real technical > reason for the /64 magic boundary. it's one of the last big pieces > of the old v6 religion. but beware that it does have some ties to > ether-like mac addresses and hence auto-numbering. I think early on people talked about having 64-bit ip addressed and then talked about easy load-balancing and allowing multiple devices to have same 64-bit internet (ISP assigned) ip address with multiple actual devices at the end that have different physical addresses. That ended up being 128bit address with first 64bits designated for internet routing and last 64bits being unique device id. Entire 64bit for device id is because currently we use /48 MACs and extra /16 was added just in case as well as to allow for different MAC-like (or not like) device-id addressing systems (and BTW with /48 bits there and many more network cards sold then we have internet- connected machines we still have not come close to exhausting those addresses) Now possibly future astronauts and nanotech-engineers will find a better use for those last /64 bits (and they will then thank use for leaving those 64 bits open) but lets not worry about that right now because the most important thing we need to do is to actually help get ipv6 deployed. As far as why /48 for end-networks that was decision done not only by IETF but also discussed at all RIRs - I remember we had voted for that on at least two ARIN meetings in around 2000-2002 (I think Las Vegas was when it was finalized) and there was a consensus about it. It can be changed, but it'd have to be the same kind of process with everyone getting involved and agreeing on the change and it would cause yet another push of ip6 deployment by several years. Plus I really don't see why we should be worrying about it when just for case like that it was decided that only 1/4 of ipv6 space will actually be open for use and rest 3/4 are reserved in case we ever actually exhaust the first 1/4 and then if we do we can surely work out a lot more serious policies as to how not to exhaust remaining 3/4 quickly... -- William Leibzon Elan Networks william at elan.net From randy at psg.com Mon Apr 25 17:38:19 2005 From: randy at psg.com (Randy Bush) Date: Mon, 25 Apr 2005 11:38:19 -1000 Subject: [ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments] References: <20050425190913.GA45127@ussenterprise.ufp.org> <17005.22163.782435.233847@roam.psg.com> Message-ID: <17005.25419.399686.269224@roam.psg.com> >> just to throw in a serious bomb, there is no actual real technical >> reason for the /64 magic boundary. it's one of the last big pieces >> of the old v6 religion. but beware that it does have some ties to >> ether-like mac addresses and hence auto-numbering. > > I think early on people talked about having 64-bit ip addressed and then > talked about easy load-balancing and allowing multiple devices to have > same 64-bit internet (ISP assigned) ip address with multiple actual > devices at the end that have different physical addresses. That ended up > being 128bit address with first 64bits designated for internet routing and > last 64bits being unique device id. Entire 64bit for device id is because > currently we use /48 MACs and extra /16 was added just in case as well as > to allow for different MAC-like (or not like) device-id addressing systems > (and BTW with /48 bits there and many more network cards sold then we have > internet- connected machines we still have not come close to exhausting > those addresses) Now possibly future astronauts and nanotech-engineers > will find a better use for those last /64 bits (and they will then thank > use for leaving those 64 bits open) but lets not worry about that right > now because the most important thing we need to do is to actually help get > ipv6 deployed. > > As far as why /48 for end-networks that was decision done not only by IETF > but also discussed at all RIRs - I remember we had voted for that on at > least two ARIN meetings in around 2000-2002 (I think Las Vegas was when it > was finalized) and there was a consensus about it. It can be changed, but > it'd have to be the same kind of process with everyone getting involved > and agreeing on the change and it would cause yet another push of ip6 > deployment by several years. Plus I really don't see why we should be > worrying about it when just for case like that it was decided that only > 1/4 of ipv6 space will actually be open for use and rest 3/4 are reserved > in case we ever actually exhaust the first 1/4 and then if we do we can > surely work out a lot more serious policies as to how not to exhaust > remaining 3/4 quickly... so, if i rephrase that there is no real CURRENT technical reason, i gather you aree. interesting side note that the binding to a mac address created all sorts of privacy issues as well, see later back-patches to v6 such as 3041. randy From lea.roberts at stanford.edu Mon Apr 25 17:41:42 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 25 Apr 2005 14:41:42 -0700 (PDT) Subject: [ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments] In-Reply-To: Message-ID: William - A large number of folks worked very hard to develop a "coordinated" IPv6 policy among all the RIRs, which included the /48 recommendation from the IETF. All of these carried the caveat that they would be revisited after "operational experience" was gained. There is now beginning to be operational experience that shows very large allocations being justified under the current criteria, which suggests revisting the policy parameters and noting that perhaps the assignment pendulum swung a little too far toward the "there should be no limits" end. Just because there is a safety valve doesn't argue for reaching that point any sooner that prudent but non-restrictive allocation policy would allow. /Lea On Mon, 25 Apr 2005, william(at)elan.net wrote: > > As far as why /48 for end-networks that was decision done not only by IETF > but also discussed at all RIRs - I remember we had voted for that on at > least two ARIN meetings in around 2000-2002 (I think Las Vegas was when it > was finalized) and there was a consensus about it. It can be changed, but > it'd have to be the same kind of process with everyone getting involved > and agreeing on the change and it would cause yet another push of ip6 > deployment by several years. Plus I really don't see why we should be > worrying about it when just for case like that it was decided that only > 1/4 of ipv6 space will actually be open for use and rest 3/4 are reserved > in case we ever actually exhaust the first 1/4 and then if we do we can > surely work out a lot more serious policies as to how not to exhaust > remaining 3/4 quickly... From william at elan.net Mon Apr 25 18:00:37 2005 From: william at elan.net (william(at)elan.net) Date: Mon, 25 Apr 2005 15:00:37 -0700 (PDT) Subject: [ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments] In-Reply-To: <17005.25419.399686.269224@roam.psg.com> References: <20050425190913.GA45127@ussenterprise.ufp.org> <17005.22163.782435.233847@roam.psg.com> <17005.25419.399686.269224@roam.psg.com> Message-ID: On Mon, 25 Apr 2005, Randy Bush wrote: > so, if i rephrase that there is no real CURRENT technical reason, Of course IETF did not want to create new CIDR. But that does not mean that such limit would not come based on operational policies and everyone wanted to make sure those policies would be the same across the board and leave and leave enough room for everyone. As an example we do have a limit of /24 and smaller blocks are not allowed by most (every!) ISPs to come into global routing table. And as far as /64 boundary it is in fact more then just policy /48 (which is similar to /24 operational bgp prefix limit) and a lot of equipment companies are already setting it up for their devices. Not in theory impossile to change but would not be easy either. > i gather you aree. interesting side note that the binding to a mac > address created all sorts of privacy issues as well, see later > back-patches to v6 such as 3041. Binding to currently used MAC addresses was never assumed to be way for future, it was always understood that multiple end-note addressing schemes would exist. Privacy reasons has just caused creation of such new scheme. What I do not like is that now people seem ok with setting up those /64 bits to just 00 or 01 - this is bad and both increases chance of collision and bad for security. -- William Leibzon Elan Networks william at elan.net From tme at multicasttech.com Mon Apr 25 18:16:32 2005 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 25 Apr 2005 18:16:32 -0400 Subject: [ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments] In-Reply-To: Message-ID: On Mon, 25 Apr 2005 14:08:29 -0700 (PDT) "william(at)elan.net" wrote: > > On Mon, 25 Apr 2005, Randy Bush wrote: > > > just to throw in a serious bomb, there is no actual real technical > > reason for the /64 magic boundary. it's one of the last big pieces > > of the old v6 religion. but beware that it does have some ties to > > ether-like mac addresses and hence auto-numbering. > > I think early on people talked about having 64-bit ip addressed and then > talked about easy load-balancing and allowing multiple devices to have same > 64-bit internet (ISP assigned) ip address with multiple actual devices at > the end that have different physical addresses. That ended up being 128bit > address with first 64bits designated for internet routing and last 64bits > being unique device id. Entire 64bit for device id is because currently we > use /48 MACs and extra /16 was added just in case as well as to allow for > different MAC-like (or not like) device-id addressing systems (and BTW > with /48 bits there and many more network cards sold then we have internet- > connected machines we still have not come close to exhausting those addresses) > Now possibly future astronauts and nanotech-engineers will find a better > use for those last /64 bits (and they will then thank use for leaving > those 64 bits open) but lets not worry about that right now because the > most important thing we need to do is to actually help get ipv6 deployed. > I think that IPv6 embedded RP multicast has shown that you can do cool things in IPv6 because you can embed an address (with some restrictions) completely inside of another one. (In embedded RP, what's embedded is the address of the RP for the multicast group, which means that interdomain ASM multicast can be done without a raft of protocol infrastructure, like MSDP.) I have a feeling that people will find other uses for those bits fairly quickly if IPv6 takes off. Regards Marshall Eubanks > As far as why /48 for end-networks that was decision done not only by IETF > but also discussed at all RIRs - I remember we had voted for that on at > least two ARIN meetings in around 2000-2002 (I think Las Vegas was when it > was finalized) and there was a consensus about it. It can be changed, but > it'd have to be the same kind of process with everyone getting involved > and agreeing on the change and it would cause yet another push of ip6 > deployment by several years. Plus I really don't see why we should be > worrying about it when just for case like that it was decided that only > 1/4 of ipv6 space will actually be open for use and rest 3/4 are reserved > in case we ever actually exhaust the first 1/4 and then if we do we can > surely work out a lot more serious policies as to how not to exhaust > remaining 3/4 quickly... > > -- > William Leibzon > Elan Networks > william at elan.net From dr at cluenet.de Mon Apr 25 18:29:56 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 26 Apr 2005 00:29:56 +0200 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: <025801c548d9$260aeb00$6601a8c0@stephen> References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> <025801c548d9$260aeb00$6601a8c0@stephen> Message-ID: <20050425222956.GA20348@srv01.cluenet.de> On Sun, Apr 24, 2005 at 09:13:48AM -0500, Stephen Sprunk wrote: > > Nope. They should get a /48 unless they can convincingly show that > > they'll never need more than a single subnet. > > It is ridiculous to think that ISPs are going to completely discard their > current IPv4 topology to deploy IPv6. Why must they discard any topology? They might have problems to charge for /48 instead of /64 if /48 becomes "usual" at the competitors, yeah. But that's primarily a business thing. > Most "residential" ISPs I'm aware of use a single subnet for N customers, Hm? I guess you are referring to cable modem stuff? Over here (DE), almost all residential users use dial-up, be it real (analog, ISDN) or virtual (DSL, via PPPoE). So they are connected via virtual interfaces, and get their IP address usually via dynamic pools or static via RADIUS. No problem adapting this to assign /48s (especially via RADIUS). > and that is perfectly reasonable to continue with IPv6 -- just assign > a /64. That allows customers to put as many hosts as they want on the > "bare" connection, and any who want their own subnet(s) can be issued > a /64 or /48 of their own And then charged additional install and monthly fee? Cool. We want to get rid of this as much as possible. Artificial scarcity sucks. In IPv4, there is the perceived scarcity excuse for ISPs. Don't recreate that in IPv6, thanks. The mantra is "/48, no questions asked, and by default". > but most will not be interested in that or even understand what it > means. So what? If done properly, someone who doesn't care can just ignore the availability of the rest. But as someone else noticed, this discussion is sliding off. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From lea.roberts at stanford.edu Mon Apr 25 19:21:46 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 25 Apr 2005 16:21:46 -0700 (PDT) Subject: [ppml] IPv6 & /48 In-Reply-To: Message-ID: it looks like Randy's bomb has produced some reverberations (thanks, Randy! :-) in any case, while I haven't looked at the embeded RP that closely, I'm assuming that as long as we stay above /64 there shouldn't be a problem? (i.e. it doesn't depend on the /48 to work?) thanks, /Lea On Mon, 25 Apr 2005, Marshall Eubanks wrote: > On Mon, 25 Apr 2005 14:08:29 -0700 (PDT) > "william(at)elan.net" wrote: > > > > On Mon, 25 Apr 2005, Randy Bush wrote: > > > > > just to throw in a serious bomb, there is no actual real technical > > > reason for the /64 magic boundary. it's one of the last big pieces > > > of the old v6 religion. but beware that it does have some ties to > > > ether-like mac addresses and hence auto-numbering. > > > > I think early on people talked about having 64-bit ip addressed and then > > talked about easy load-balancing and allowing multiple devices to have same > > 64-bit internet (ISP assigned) ip address with multiple actual devices at > > the end that have different physical addresses. That ended up being 128bit > > address with first 64bits designated for internet routing and last 64bits > > being unique device id. Entire 64bit for device id is because currently we > > use /48 MACs and extra /16 was added just in case as well as to allow for > > different MAC-like (or not like) device-id addressing systems (and BTW > > with /48 bits there and many more network cards sold then we have internet- > > connected machines we still have not come close to exhausting those addresses) > > Now possibly future astronauts and nanotech-engineers will find a better > > use for those last /64 bits (and they will then thank use for leaving > > those 64 bits open) but lets not worry about that right now because the > > most important thing we need to do is to actually help get ipv6 deployed. > > > > I think that IPv6 embedded RP multicast has shown that you can do cool things > in IPv6 because you can embed an address (with some restrictions) > completely inside of another one. > (In embedded RP, what's embedded is the address of the RP for the multicast > group, which means that interdomain ASM multicast can be done without a raft of protocol > infrastructure, like MSDP.) > > I have a feeling that people will find other uses for those bits fairly quickly if IPv6 > takes off. > > Regards > Marshall Eubanks > > > As far as why /48 for end-networks that was decision done not only by IETF > > but also discussed at all RIRs - I remember we had voted for that on at > > least two ARIN meetings in around 2000-2002 (I think Las Vegas was when it > > was finalized) and there was a consensus about it. It can be changed, but > > it'd have to be the same kind of process with everyone getting involved > > and agreeing on the change and it would cause yet another push of ip6 > > deployment by several years. Plus I really don't see why we should be > > worrying about it when just for case like that it was decided that only > > 1/4 of ipv6 space will actually be open for use and rest 3/4 are reserved > > in case we ever actually exhaust the first 1/4 and then if we do we can > > surely work out a lot more serious policies as to how not to exhaust > > remaining 3/4 quickly... > > > > -- > > William Leibzon > > Elan Networks > > william at elan.net > From tme at multicasttech.com Mon Apr 25 20:01:44 2005 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 25 Apr 2005 20:01:44 -0400 Subject: [ppml] IPv6 & /48 In-Reply-To: Message-ID: On Mon, 25 Apr 2005 16:21:46 -0700 (PDT) Lea Roberts wrote: > it looks like Randy's bomb has produced some reverberations (thanks, > Randy! :-) > > in any case, while I haven't looked at the embeded RP that closely, I'm > assuming that as long as we stay above /64 there shouldn't be a problem? > (i.e. it doesn't depend on the /48 to work?) The details are in RFC3956 http://www.ietf.org/rfc/rfc3956.txt Remember, multicast addresses don't have MAC embedding. A full (up to 64 bits) unicast RP address is embedded in a full 128 bit multicast address with the potential of setting the 4 bits at the end - i.e., no attempt is made to embed the Mac address. This takes 96 bits with overhead. Regards Marshall > > thanks, /Lea > > On Mon, 25 Apr 2005, Marshall Eubanks wrote: > > > On Mon, 25 Apr 2005 14:08:29 -0700 (PDT) > > "william(at)elan.net" wrote: > > > > > > On Mon, 25 Apr 2005, Randy Bush wrote: > > > > > > > just to throw in a serious bomb, there is no actual real technical > > > > reason for the /64 magic boundary. it's one of the last big pieces > > > > of the old v6 religion. but beware that it does have some ties to > > > > ether-like mac addresses and hence auto-numbering. > > > > > > I think early on people talked about having 64-bit ip addressed and then > > > talked about easy load-balancing and allowing multiple devices to have same > > > 64-bit internet (ISP assigned) ip address with multiple actual devices at > > > the end that have different physical addresses. That ended up being 128bit > > > address with first 64bits designated for internet routing and last 64bits > > > being unique device id. Entire 64bit for device id is because currently we > > > use /48 MACs and extra /16 was added just in case as well as to allow for > > > different MAC-like (or not like) device-id addressing systems (and BTW > > > with /48 bits there and many more network cards sold then we have internet- > > > connected machines we still have not come close to exhausting those addresses) > > > Now possibly future astronauts and nanotech-engineers will find a better > > > use for those last /64 bits (and they will then thank use for leaving > > > those 64 bits open) but lets not worry about that right now because the > > > most important thing we need to do is to actually help get ipv6 deployed. > > > > > > > I think that IPv6 embedded RP multicast has shown that you can do cool things > > in IPv6 because you can embed an address (with some restrictions) > > completely inside of another one. > > (In embedded RP, what's embedded is the address of the RP for the multicast > > group, which means that interdomain ASM multicast can be done without a raft of protocol > > infrastructure, like MSDP.) > > > > I have a feeling that people will find other uses for those bits fairly quickly if IPv6 > > takes off. > > > > Regards > > Marshall Eubanks > > > > > As far as why /48 for end-networks that was decision done not only by IETF > > > but also discussed at all RIRs - I remember we had voted for that on at > > > least two ARIN meetings in around 2000-2002 (I think Las Vegas was when it > > > was finalized) and there was a consensus about it. It can be changed, but > > > it'd have to be the same kind of process with everyone getting involved > > > and agreeing on the change and it would cause yet another push of ip6 > > > deployment by several years. Plus I really don't see why we should be > > > worrying about it when just for case like that it was decided that only > > > 1/4 of ipv6 space will actually be open for use and rest 3/4 are reserved > > > in case we ever actually exhaust the first 1/4 and then if we do we can > > > surely work out a lot more serious policies as to how not to exhaust > > > remaining 3/4 quickly... > > > > > > -- > > > William Leibzon > > > Elan Networks > > > william at elan.net > > > > From david.conrad at nominum.com Mon Apr 25 20:28:46 2005 From: david.conrad at nominum.com (David Conrad) Date: Mon, 25 Apr 2005 17:28:46 -0700 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: <20050425222956.GA20348@srv01.cluenet.de> References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> <025801c548d9$260aeb00$6601a8c0@stephen> <20050425222956.GA20348@srv01.cluenet.de> Message-ID: <09caf590cd7f11387ff2c0ec08bfb1f3@nominum.com> On Apr 25, 2005, at 3:29 PM, Daniel Roesen wrote: >> That allows customers to put as many hosts as they want on the >> "bare" connection, and any who want their own subnet(s) can be issued >> a /64 or /48 of their own > And then charged additional install and monthly fee? Cool. We want to > get rid of this as much as possible. Artificial scarcity sucks. In > IPv4, > there is the perceived scarcity excuse for ISPs. Don't recreate that in > IPv6, thanks. > > The mantra is "/48, no questions asked, and by default". In the past, when ideology and mantras ran up against business models and operational requirements, ideology and mantras, particularly those that can be argued to have been chosen arbitrarily, have generally lost. But maybe that's just my experiences. Rgds, -drc From william at elan.net Mon Apr 25 21:25:04 2005 From: william at elan.net (william(at)elan.net) Date: Mon, 25 Apr 2005 18:25:04 -0700 (PDT) Subject: [ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2005, Lea Roberts wrote: > A large number of folks worked very hard to develop a "coordinated" IPv6 > policy among all the RIRs, which included the /48 recommendation from the > IETF. And I'm very grateful to people involved and I'm sure all of us thank them for all the work done. But despite best efforts as to global RIR coordination, the uniform policy did not last more then 1 years... Now, I'm not saying it was bad that we have have worked together, but I do think that beyond some general standards as to prefix size that do need overall RIR & IETF coordination (like this /48), the actual details of the policies do not necessarily need to be exactly the same for each RIR, so if we get consensus for micro-allocations in ARIN region for IP6, we should go ahead. > All of these carried the caveat that they would be revisited after > "operational experience" was gained. Do you really believe we now have lot more operational experience with IP6 in just last 2 years? And in ARIN region? Be serious! > There is now beginning to be operational experience that shows very > large allocations being justified under the current criteria, which In other messages you mentioned that these very large allocations are /19 in RIPE region. This does not necessarily means its /48 boundary that is causing it and it maybe that general allocation policy is too lax or allows for too large an initial assignment and adjusting such policies could be enough without necessity to actually change /48. In any case as this is a problem being seen at the RIPE region, they should analyze it first and then if they believe changing /48 boundary is best way to reduce requests for these large allocations, they can certainly come to all RIRs and we should consider it. > suggests revisting the policy parameters and noting that perhaps the > assignment pendulum swung a little too far toward the "there should be > no limits" end. Just because there is a safety valve doesn't argue for > reaching that point any sooner that prudent but non-restrictive > allocation policy would allow. Lets talk numbers, shall we? Lets assume for the moment that absolutely every person/end-user connected to IP6 Internet global network is going to have a local lan and will thus justify /48 (and not just /64). Now taking into account that all assignments in ip6 are made from /2 (leaving 3/4 space in reserve) we have 2^46 or slightly over 2.8x10^14 (about 281,000 billion!) of such /48 nets to assign to users - for comparison in case you don't know, the number of people on earth right now is 6 billion and most doubt the earth could sustain more then 20 or 30, lets take 30 for now, which is 30*10^9 and is still 100,000 times larger then number of ip nets that can be assigned! Now another interesting way to look at it is to compare RIR ISP allocations in ip4 and in ip6. Again lets assume that every end-user gets /48 in ip6 instead of single ip address as done with ip4. With IP4 current ISPs get allocated from /22 to /8 from RIRs (in case you don't know last ARIN block of 73/8 was allocated almost entirely to Comcast), so there is wide variety of sizes of allocation depending on the size and needs of the ISP. So how does that compare to IP6? Well /8 to one ISP is 2^24 of ip addresses and for ip6 2^24 /48 netblocks is allocation size of /24 - true, this is smaller then /19 that somebody got, but its no longer then far off. Plus lets now consider that smaller ISPs with IP4 get /20 (/22 with micro-allocation policy) where as with IP6 they all justify /32. The difference between /20 and /8 is 2^12 which is almost exactly the difference between /32 and /19 (there its 2^13). So what I see is that RIPE might have applied in their allocations the difference as way to justify that large block rather then deciding it based purely on number of ip addresses (netblocks) needed. I think this is something that their policy can fix to bring maximum assigned block to one entity to something like /24 (i.e. comparable to /8 in ip4). Also even if RIRs continue to have to allocate /19s to some LIRs/ISPs, is it really such a big immediate problem? In IP4 space, we have total of 256 /8 with less then 1/2 in use, but lets take it as full 256 /8 nets. Now lets assume that everyone who has /8 in ip4 can manage to get /19 ip6 from RIR. That means that /11 would be consumed by such allocations - and that is out of /2 that we have - it is still just 1/16th of the pool! Now, I don't know if my math convinced you, but I REALLY don't see those numbers as being of immediate concern to change allocation and move away from /48 boundary. -- William Leibzon Elan Networks william at elan.net From dr at cluenet.de Tue Apr 26 01:25:16 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 26 Apr 2005 07:25:16 +0200 Subject: [ppml] Re: IPv6 & /48 [was 2005-1:Business Need for PI Assignments] In-Reply-To: References: Message-ID: <20050426052516.GA23961@srv01.cluenet.de> On Mon, Apr 25, 2005 at 06:25:04PM -0700, william(at)elan.net wrote: > Plus lets now consider that smaller ISPs with IP4 get /20 (/22 with > micro-allocation policy) where as with IP6 they all justify /32. The > difference between /20 and /8 is 2^12 which is almost exactly the > difference between /32 and /19 (there its 2^13). So what I see is that > RIPE might have applied in their allocations the difference as way to > justify that large block rather then deciding it based purely on number > of ip addresses (netblocks) needed. Justification for the large IPv6 allocations in RIPE land were simply done based on HD ratio. http://www.ripe.net/ripe/docs/ipv6policy.html#hd_ratio http://www.ripe.net/ripe/docs/ipv6policy.html#applied_hd_ratio So customer count directly translates to allocation size: http://www.ripe.net/ripe/docs/ipv6policy.html#appendixA A customer count of over 5.5-9.5 million translates to IPv6 /19. Just to add some facts to the speculation on how RIPE handles large requests. :-)= Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From owen at delong.com Tue Apr 26 02:11:58 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Apr 2005 23:11:58 -0700 Subject: [ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments] In-Reply-To: References: Message-ID: <2147483647.1114470718@[172.17.1.152]> Lea, Thanks for changing the thread. Everyone, Personally, I can't see that the average home user needs more than a /64, and, possibly a /128. I think that users should have the ability to get whatever they need, but, the default allocation for a single home should be no shorter than /64. I have no problem with issuing /56, or, even /60s to individual users. I have always considered the /48 gospel to be somewhat silly. If someone needs a more than a /64, let's give them a /60. If they need more than a /60, let's give them a /56. If they need more than a /56, let's give them a /48, but, let's not burn address space just to burn address space. 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 Michael.Dillon at radianz.com Tue Apr 26 05:03:38 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 26 Apr 2005 10:03:38 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: Message-ID: > What I mean is - I have yet to be convinced that there is a concrete > reason to assign gobs of addresses to my house. Why not dole out > IPv6 a few addresses at a time until it's clear I need a /48 or /52 > or /60. Because history has shown that this is a *BAD* idea. This thinking is behind telephone billing systems. Why should you pay for the time when you are not making a phonecall? It sounds logical but we know that the end result was in the mid 1990's, 75% of the cost of the telecom systems was in the telephone billing systems and the support for billing systems throughout the network. Do we want to recreate this with IPv6? The lesson of flat rate billing systems is that it is cheaper overall for everyone when you just overprovision the network and just share the costs according to a simple, predictable, pre-calculated system. It may seem that bandwidth is wasted, but the alternative is to waste money on complex billing and accounting systems. IPv6 may appear to waste addresses but in reality, it is spending those addresses to buy a simpler overall addressing architecture that saves everyone money. Simple is good. > My lack of addresses (when I am home) isn't what's holding > back innovation. Wouldn't my squandering addresses be a bigger risk > to future innovation? Not at all. Innovation comes about when traditional ways of doing things can no longer cope. It has nothing to do with IPv6 address conservation. If we run out of IPv6 addresses in the year 2105, then that may spark some innovation. --Michael Dillon From Michael.Dillon at radianz.com Tue Apr 26 05:21:19 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 26 Apr 2005 10:21:19 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <20050425164516.GA38607@ussenterprise.ufp.org> Message-ID: > > The question of waste has to do with the environment you are in, the sources > > of supply, and the difficulty of obtaining a resource. IPv6 addresses may > > Your analogy here holds more water than you might think. > > Water, like IPv6 addresses, is abundant. > Drinkable water, like usable IPv6 addresses, is not. That's because the RIRs are hording the vast supply of fresh clean water in their reservoir. > Using a /64 for a "LAN" is like dumping raw sewage into the water > and then wondering why it's contaminated. Now you are mixing metaphors. Using addresses is like using water. It's not like adding something to the water. And using a /64 for a single LAN subnet is just good practice in compliance with the IPv6 RFCs. Again, your thinking is stuck in the old-fashioned world of IPv4. We cannot make good IPv6 policy if we insist on treating the IPv6 address space just like the IPv4 address space. We have to learn from our IPv4 experience and move on. Learning implies that we have gained understanding and that we can make new decisions rather than slavishly imitating the past. I know this is hard to do and requires some innovative and creative thinking, but that is what must be done to create a sensible IPv6 policy. > Now, I'll be the first to > admit I'd like to not have to use 1918 space for the 650 subnets I > have at home behind my 3Mbps cable modem, but giving me 100 times > that again prevents someone else from using the space who might > actually need it. This is quite simply, wrong! If your ISP were to give you a /48 for a single home subnet with 2 computers, that would not preven anyone else from getting IPv6 address space until sometime after your natural death from old age. Of course, at that point we can reuse your /48, your house and any other possessions that you may have left behind. With IPv4 we were worried about whether there would be any addresses left for our kids to use. With IPv6 we know that the address space will last longer than any human currently living on this planet. > We have people who are talking about allocating IPv6 addresses to > serve a 60 year need. Well, that's all well and good, but it's > only 40 years after the doorknob quote and the reality is quite > different. Ideas that seem far fetched today like colonizing mars, > or faster than light travel, or nanomachines that have IP stacks > may be so common place in 60 years time that no one gives them a > second thought. Seriously, if we discover 60 years from now, that we have made a mistake with IPv6, then we will also have the knowledge and the ability to create a replacement for IPv6. Or to recover unused addresses. Or something else. RIR policy does not have to be good enough forever. It just has to be good enough for today, and for the foreseeable future. We don't want to penalize today in order to support the unforeseeable future because in doing so, we may never be able to reach that unforeseeable future. > What's most absurd about things like a /48 for cable modem users > is that it only promotes waste. No, the absurd thing is calling unused addresses "waste". Unused addresses are inherent in the notion of IP, whether v4 or v6. It has to do with the hierarchichal addressing system that allows ranges of addresses to be treated in aggregate by IP routers. It is fundamental to the concept of IP and we must live with that. Given this fact, it is unwise to call this "waste". In IPv4, there is such a thing as "waste" when an address range is oversized. But in IPv6, everybody gets a /48, every subnet gets a /64. Where is the waste? This is not where we make our policies. The RIRs really should only be deciding the criteria for handing out a /32 or larger block of IPv6 addresses. And if an organization is going to announce their addreses in the global routing table, then I think that justifies giving out a /32. If there is a concern about who should and should not announce addresses in the global routing table, then that should be dealt with in AS number policy. --Michael Dillon From Ed.Lewis at neustar.biz Tue Apr 26 09:25:00 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 26 Apr 2005 09:25:00 -0400 Subject: v4 v v6 - Re: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: At 10:21 +0100 4/26/05, Michael.Dillon at radianz.com wrote: >I know this is hard to do and requires some innovative and >creative thinking, but that is what must be done to create a >sensible IPv6 policy. What tangible differences are there between v4 and v6 when it comes to addressing? How about some examples, some "for instance..."s? Here's why I think it's not wise to set a policy because of things that require innovative and creative thinking... Are subnets in the home-area-network future? If you have a fast back plane network hub with interfaces for each addressed device in the house, troubleshooting tools adequate for the job, and interface cards able to filter in desired traffic, is there a need for subnetting? Are subnets a given - are they justification for IPv6 policy being different from IPv4? There are many possible futures out there, that's my point. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From lea.roberts at stanford.edu Tue Apr 26 10:07:28 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Tue, 26 Apr 2005 07:07:28 -0700 (PDT) Subject: IPv6 & /48 Re: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: Message-ID: Your analogy is equally faulty. Reassignments are done once, whether it's being given a fixed block or dynamic prefix assignment. It's still a flat rate network service. and don't kid yourself... inside networks there will be lots of prefixes of different lengths distributed in the routing systems. like you say it's what gets announced into the global space that needs constraint. On Tue, 26 Apr 2005 Michael.Dillon at radianz.com wrote: > > What I mean is - I have yet to be convinced that there is a concrete > > reason to assign gobs of addresses to my house. Why not dole out > > IPv6 a few addresses at a time until it's clear I need a /48 or /52 > > or /60. > > Because history has shown that this is a *BAD* idea. This thinking > is behind telephone billing systems. Why should you pay for the > time when you are not making a phonecall? It sounds logical but we > know that the end result was in the mid 1990's, 75% of the cost of > the telecom systems was in the telephone billing systems and the > support for billing systems throughout the network. Do we want to > recreate this with IPv6? > > The lesson of flat rate billing systems is that it is cheaper overall > for everyone when you just overprovision the network and just share > the costs according to a simple, predictable, pre-calculated system. > It may seem that bandwidth is wasted, but the alternative is to waste > money on complex billing and accounting systems. IPv6 may appear to > waste addresses but in reality, it is spending those addresses to buy > a simpler overall addressing architecture that saves everyone money. > Simple is good. > > > My lack of addresses (when I am home) isn't what's holding > > back innovation. Wouldn't my squandering addresses be a bigger risk > > to future innovation? > > Not at all. Innovation comes about when traditional ways of doing > things can no longer cope. It has nothing to do with IPv6 address > conservation. If we run out of IPv6 addresses in the year 2105, then > that may spark some innovation. > > --Michael Dillon > From owen at delong.com Tue Apr 26 15:56:49 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Apr 2005 12:56:49 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: <1AC94AA95F138F7F14C0CDE5@imac-en0.delong.sj.ca.us> --On Tuesday, April 26, 2005 10:03 AM +0100 Michael.Dillon at radianz.com wrote: >> What I mean is - I have yet to be convinced that there is a concrete >> reason to assign gobs of addresses to my house. Why not dole out >> IPv6 a few addresses at a time until it's clear I need a /48 or /52 >> or /60. > Look, I'm all for simple, but, oversimplification is costly, and, the current IPv6 addressing architecture is oversimplified and, in my opinion, just silly. It strives for economies where costs are already minimal. It's very nearly as simple to assign each residential or small end user a /64 unless they request more. Assigning more in the case of such a request is also simple. I agree that we shouldn't go quite as tight as current CIDR (prefixes of all shapes and sizes), but, rounding requests to 4 or 8 bit boundaries seems a perfectly reasonable compromise to me. I just don't see a lot of economy to 16 bit rounding compared to the amount of waste. > Not at all. Innovation comes about when traditional ways of doing > things can no longer cope. It has nothing to do with IPv6 address > conservation. If we run out of IPv6 addresses in the year 2105, then > that may spark some innovation. > So you're saying we should waste addresses today in order to limit the useful live of IPv6 because that will accelerate our development of the next protocol. Michael, you have a unique way of viewing the world. Personally, I'd like to see us try and find ways to make whatever protocol we implement next (IPv6 being the currently most likely candidate) last as long as possible. There are plenty of other areas where innovation is needed. 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 Apr 26 16:57:50 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Apr 2005 13:57:50 -0700 Subject: [ppml] an interesting debate about v6 [was sort of about 2005-1] Message-ID: <45722915FA6EC03188BCD382@imac-en0.delong.sj.ca.us> > I think it is relevant to the policy. If Michael Dillon is claiming that > v6 is different from v4 then the policies between the two are different. > If he's wrong, then why do we have a v4 track and a v6 track. > Michael is neither right or wrong in this case, it's a question of degree. v6 has bigger addresses than v4. There are some other differences, but, by and large, they are more subtle than the address size. Micahel is arguing that the difference in address size warrants a whole new paradigm of how we consider addresses, and, that the abundance of them means that we should look for other efficiencies no matter how many of them we waste. Of course, if you read all of Michael's postings, you discover that part of his apparent motification for this is a desire to exhaust the IPv6 address space in favor of sparking the next innovation. Personally, I don't share this particular desire. > The point he states and my questioning it are related to the very need > for the policy. Perhaps not the contents of the policy, but whether it > is needed at all. > Well... There are two competing theories on this: 1. V6 must provide all the capabilities of V4 and some advantage, or, people will not adopt V6. There is reason to believe that the internet should move towards V6 because a lot of the current hacks to keep V4 alive are starting to bulge at the seams. As such, there are good reasons to encourage V6 deployment. 2. V6 must remain architecturally pure and we must never again create a non-aggregatable swamp of address space that will cause routers to overflow when the DFZ prefix table becomes too large. I believe that number 1 is the more compelling argument. Not that there isn't some validity to number 2, but, it has, in my opinion, a number of fallacies. + The only limit in the current policies is a 2^32 (~4 billion) route table, which, no conceivable router is capable of supporting. + Provider lockin and other problems of PA space are why there was support for 2002-3, 2003-15 (IPv4 Microallocation policies), and, these problems are identical in V6. + Operational experience has already taught us that 2002-3 did not create a run on IPv4 space as was predicted by the anti-PI crowd. Therefore, the claim that 2005-1 would create a run on ASNs is specious. I doubt it will even create a significant run on V6 implementation. However, it will allow a number of organizations which, under the current circumstances are saying "IPv6 -- Hell NO" to implement v6 because this is their primary problem with v6. Why give up capabilities (tied to PI) that I have in v4 in order to migrate to v6? >> The polciy is about trying to provide PI space to end sites because no >> practical alternative has been developed or deployed. The differences >> between V6 and V4 are marginally relevant at best, and, the debate >> about prefixes smaller than /48 doesn't seem particularly useful, as the >> major oppositions to this policy were: >> >> + Concern that too many routing slots would be used >> (longer prefixes only exacerbate this possibility) >> >> + Concern that the policy would create a run on ASNs >> (prefix length does nothing about this concern) > > And whether the policy is needed at all. > Well... I would say that this policy is the v6 equivalent to 2002-1, and, the community felt that 2002-1 was needed. I guess the real question is do we want to see v6 deployed, or, let it die on the vine? If we want to watch it die, then, rejecting this policy is a good idea. If we want to see it deployed, then, I think this policy, or, some equivalent is absolutely necessary. Worst of all, I think that some equivalent is already taking shape in the form of ULA. >> Yes... I read RFCs all the time. I also review IETF mailing list >> archives. If an ID is no longer archived, then, said ID was superceeded >> by another ID or an RFC, so, most of what you need should be in the new >> ID or RFC. > > Time to pick in the IETF... > > Not all IDs are superceeded. > True... Some are simply abandoned as a bad idea, but, in that case, they're still not particularly relevant. > When I was asked to put in a writing requirement into my networks class, > I had students try to summarize current activity in a WG or area. When > grading time came, I found that the students were up against a larger > task than I imagined. > Interesting. I haven't found it to be that much of a problem for any currently active WG. > Relying on personal contacts is not scaleable, and is no way to build a > solid technology or society. This is why the IETF is dying off. BTW, I > am a very active person in the DNS area - still, I think the organization > is moribund. > Agreed. > Enough of me picking on the IETF. > I was not defending the IETF. There are lots of things wrong with the IETF. However, my point was that PPML is not the place to repair IETF. >> Sure, IDs and RFCs could be improved. However, these are the resources >> that are available. PPML certainly isn't the place to learn why the >> IETF did or didn't do something in a particular way. > > PPML is there to vet the results of the IETF. We are not slaves to the > IETF... > We are not slaves to IETF. However, neither is the role of PPML intended to be vetting the results of IETF. PPML is to set resource allocation policy in the ARIN region. There is some overlap between this and the output of IETF, and, sometimes when the output of IETF doesn't make sense, we have to say something and make contrary policy accordingly. However, it is not on topic for PPML to: + Try to fix IETF + Try to replace the resources lacking in IETF educational areas + Debate protocol design or make changes to protocols >> Huh? I haven't killed the thread. My mind isn't made up on the topic. >> I simply asked us to refocus on the parts of the discussion that are >> relevant to 2005-1. I'm not trying to silence you or kill anything. >> I'm just trying to focus one particular discussion on it's original >> intent. > > (The "huh?" stuff is a bit off-putting.) > It was an expression of confusion and utter dismay at your statement. > I'd suggest then asking questions about what you think need to be > discussed instead of trying to silence discussions others think need to > be aired. > I wasn't trying to silence anything. I was trying to get the discussion about a policy I wrote back onto the topic of the policy. I'm taking this back to the list at this point, but, I've changed the topic. > My point of view is - the fewer policies the better, and the fewer unique > policies, even better. Why should there be a policy that is specific to > v6? That is what I'm trying learn in this discussion. However, that's not a 2005-1 question. That's a much more general question. There ALREADY is specific and separate V6 policy. There are a number of differences in V6 (address size for one) which require different policy. Different policy already exists. This proposal, if anything, makes V6 policy more like V4 policy than current V6 policy. That's why I think your questions, while relevant, are off topic for 2005-1. 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 Michael.Dillon at radianz.com Wed Apr 27 05:26:54 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 27 Apr 2005 10:26:54 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <1AC94AA95F138F7F14C0CDE5@imac-en0.delong.sj.ca.us> Message-ID: > --On Tuesday, April 26, 2005 10:03 AM +0100 Michael.Dillon at radianz.com > wrote: One of the reasons why I get rid of lines like this when I reply to an email is because it is hard to keep track of exactly who said what beyond the message to which you are replying. > >> What I mean is - I have yet to be convinced that there is a concrete > >> reason to assign gobs of addresses to my house. Why not dole out > >> IPv6 a few addresses at a time until it's clear I need a /48 or /52 > >> or /60. For example, I didn't say this, Ed Lewis did. > > Not at all. Innovation comes about when traditional ways of doing > > things can no longer cope. It has nothing to do with IPv6 address > > conservation. If we run out of IPv6 addresses in the year 2105, then > > that may spark some innovation. > > > So you're saying we should waste addresses today in order to limit the > useful live of IPv6 because that will accelerate our development of the > next protocol. Michael, you have a unique way of viewing the world. And one of the reasons that I avoid mentioning names in replies is because it requires extra work to make sure that I really am replying to the train of thought of the named individual. It also leads to personal clashes which are not terribly fruitful. Here, you actually are quoting something that I wrote on fragmentation, but you are slandering me as well because this reference to my name again implies that I wrote Ed Lewis's words above. It is better to restrict the conversation to ideas and not the personalities behind them. If you don't like the personalities, then don't reply to their messages at all. For instance, as a matter of policy, I never reply to anything written by Jeff Williams. --Michael Dillon From Michael.Dillon at radianz.com Wed Apr 27 05:29:52 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 27 Apr 2005 10:29:52 +0100 Subject: [ppml] an interesting debate about v6 [was sort of about 2005-1] In-Reply-To: <45722915FA6EC03188BCD382@imac-en0.delong.sj.ca.us> Message-ID: > Of course, if you read all of Michael's postings, you discover that part > of his apparent motification for this is a desire to exhaust the IPv6 > address space in favor of sparking the next innovation. Personally, I > don't share this particular desire. Again, you are slandering me. Your particular misunderstanding of my words is not the same thing as my words. If you insist on misunderstanding what I have written, then please do so entirely under your own name and do not mention mine. This is not People magazine. It is the ARIN Public Policy mailing list. --Michael Dillon From owen at delong.com Wed Apr 27 06:31:40 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Apr 2005 03:31:40 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: <2147483647.1114572700@[172.17.1.152]> MD>> > Not at all. Innovation comes about when traditional ways of doing MD>> > things can no longer cope. It has nothing to do with IPv6 address MD>> > conservation. If we run out of IPv6 addresses in the year 2105, then MD>> > that may spark some innovation. >> > OD>> So you're saying we should waste addresses today in order to limit the OD>> useful live of IPv6 because that will accelerate our development of the OD>> next protocol. Michael, you have a unique way of viewing the world. > MD> And one of the reasons that I avoid mentioning names in replies is MD> because it requires extra work to make sure that I really am replying MD> to the train of thought of the named individual. It also leads to MD> personal clashes which are not terribly fruitful. Here, you actually MD> are quoting something that I wrote on fragmentation, but you are MD> slandering MD> me as well because this reference to my name again implies that I wrote MD> Ed Lewis's words above. > Michael, It was not my intent to slander you, and, I had no delusion that you were responsible for Ed's words. I think my reply was focused entirely on your statement, however, I left Ed's words in for context because your words made little sense without them. MD> It is better to restrict the conversation to ideas and not the MD> personalities MD> behind them. If you don't like the personalities, then don't reply to MD> their MD> messages at all. For instance, as a matter of policy, I never reply to MD> anything written by Jeff Williams. > Again, while I mentioned you by name in this case, it was not intended as a personal attack. I know we often disagree, but, I think I have always respected you in those disagreements. I mentioned your name only to clarify which portion of the quoted text my reply was directed towards. Hopefully my attribution clarifications above will address your concerns on this message: OD = Owen DeLong MD = Michael Dillon BTW, as near as I can tell, you didn't address my interpretation of your statement. Can I presume from that, my interpretation was your intended meaning? 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 Michael.Dillon at radianz.com Wed Apr 27 07:21:16 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 27 Apr 2005 12:21:16 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <2147483647.1114572700@[172.17.1.152]> Message-ID: > BTW, as near as I can tell, you didn't address my interpretation > of your statement. Can I presume from that, my interpretation was your > intended meaning? You can, but you would be wrong. Quite frankly, I have lost the thread of this whole debate. Let's summarize by saying that you and I have a rather different world view and consequently, we tend to attach different meanings to an English sentence. I'll let the readers decide which of us is more right as I suspect that neither of us is 100% right. --Michael Dillon From jwkckid1 at ix.netcom.com Wed Apr 27 09:26:04 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 27 Apr 2005 06:26:04 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments References: Message-ID: <426F92EB.487475F6@ix.netcom.com> Michael and all, I see that you violated your own policy regarding mentioning names again. I also see that after a number of years you still have trouble following threads on Emails. And finally, I see your attitude against me or others you don't prefer is still very prevalent. As such, as a matter of good policy discussion and determination, leadership is not an area of endeavor advisable for those that harbor such prevalent and distinct attitudes. All this aside however, it is relevant that issues are directly and indirectly connected with individuals whom are providing some ideas as to how to determine policy's by which to address them. Michael.Dillon at radianz.com wrote: > > --On Tuesday, April 26, 2005 10:03 AM +0100 Michael.Dillon at radianz.com > > wrote: > > One of the reasons why I get rid of lines like this when I > reply to an email is because it is hard to keep track of exactly > who said what beyond the message to which you are replying. > > > >> What I mean is - I have yet to be convinced that there is a concrete > > >> reason to assign gobs of addresses to my house. Why not dole out > > >> IPv6 a few addresses at a time until it's clear I need a /48 or /52 > > >> or /60. > > For example, I didn't say this, Ed Lewis did. > > > > Not at all. Innovation comes about when traditional ways of doing > > > things can no longer cope. It has nothing to do with IPv6 address > > > conservation. If we run out of IPv6 addresses in the year 2105, then > > > that may spark some innovation. > > > > > So you're saying we should waste addresses today in order to limit the > > useful live of IPv6 because that will accelerate our development of the > > next protocol. Michael, you have a unique way of viewing the world. > > And one of the reasons that I avoid mentioning names in replies is > because it requires extra work to make sure that I really am replying > to the train of thought of the named individual. It also leads to > personal clashes which are not terribly fruitful. Here, you actually > are quoting something that I wrote on fragmentation, but you are > slandering > me as well because this reference to my name again implies that I wrote > Ed Lewis's words above. > > It is better to restrict the conversation to ideas and not the > personalities > behind them. If you don't like the personalities, then don't reply to > their > messages at all. For instance, as a matter of policy, I never reply to > anything written by Jeff Williams. > > --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 Ed.Lewis at neustar.biz Wed Apr 27 07:33:02 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 27 Apr 2005 07:33:02 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: At 10:26 +0100 4/27/05, Michael.Dillon at radianz.com wrote: >For example, I didn't say this, Ed Lewis did. That's right. My words were not meant to be a characterization of anything Michael said. Owen improperly posted a message from a private conversation he and I were having, i.e., without permission and without giving the context. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From jwkckid1 at ix.netcom.com Wed Apr 27 09:36:57 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 27 Apr 2005 06:36:57 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments References: <2147483647.1114572700@[172.17.1.152]> Message-ID: <426F9578.2ACE0BB4@ix.netcom.com> Owen and all, Both sides of this issue and/or argument have merit. On one side a more conservative and restrictive approach is helpful for longer term address availability and prevention of wasted allocations. On the other more liberal side and/or approach preferred by some, is in part the idea that a more liberal allocation policy will aid in the migration from Ipv4 to Ipv6 for good or ill. It may be that some middle ground is satisfactory to both entrenched sides of this divide in terms of policy?! Or am I all wet here? Owen DeLong wrote: > MD>> > Not at all. Innovation comes about when traditional ways of doing > MD>> > things can no longer cope. It has nothing to do with IPv6 address > MD>> > conservation. If we run out of IPv6 addresses in the year 2105, then > MD>> > that may spark some innovation. > >> > > OD>> So you're saying we should waste addresses today in order to limit the > OD>> useful live of IPv6 because that will accelerate our development of the > OD>> next protocol. Michael, you have a unique way of viewing the world. > > > MD> And one of the reasons that I avoid mentioning names in replies is > MD> because it requires extra work to make sure that I really am replying > MD> to the train of thought of the named individual. It also leads to > MD> personal clashes which are not terribly fruitful. Here, you actually > MD> are quoting something that I wrote on fragmentation, but you are > MD> slandering > MD> me as well because this reference to my name again implies that I wrote > MD> Ed Lewis's words above. > > > Michael, > It was not my intent to slander you, and, I had no delusion > that you were responsible for Ed's words. I think my reply was > focused entirely on your statement, however, I left Ed's words in > for context because your words made little sense without them. > > MD> It is better to restrict the conversation to ideas and not the > MD> personalities > MD> behind them. If you don't like the personalities, then don't reply to > MD> their > MD> messages at all. For instance, as a matter of policy, I never reply to > MD> anything written by Jeff Williams. > > > > Again, while I mentioned you by name in this case, it was not > intended as a personal attack. I know we often disagree, but, I think > I have always respected you in those disagreements. I mentioned your > name only to clarify which portion of the quoted text my reply was > directed towards. > > Hopefully my attribution clarifications above will address > your concerns on this message: > > OD = Owen DeLong > MD = Michael Dillon > > BTW, as near as I can tell, you didn't address my interpretation > of your statement. Can I presume from that, my interpretation was your > intended meaning? > > Owen > > -- > If this message was not signed with gpg key 0FE2AA3D, it's probably > a forgery. > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit 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 jwkckid1 at ix.netcom.com Wed Apr 27 09:45:19 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 27 Apr 2005 06:45:19 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments References: Message-ID: <426F976E.50E59B3D@ix.netcom.com> Ed and all, Oh my! What a terrible shock for you Ed! Such a thing doesn't follow your form of proper Email forum use! How terrible for you! Ok so now can we stop this petty bickering please?! Edward Lewis wrote: > At 10:26 +0100 4/27/05, Michael.Dillon at radianz.com wrote: > > >For example, I didn't say this, Ed Lewis did. > > That's right. My words were not meant to be a characterization of > anything Michael said. Owen improperly posted a message from a > private conversation he and I were having, i.e., without permission > and without giving the context. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > If you knew what I was thinking, you'd understand what I was saying. 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 billd at cait.wustl.edu Wed Apr 27 08:49:18 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 27 Apr 2005 07:49:18 -0500 Subject: [ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignment s] Message-ID: This...in my opinion is THE biggest issue that impacts the v6 ability to achieve the 2 objectives it most needs to accomplish..... Easy administration without renumbering or returning for more....AND relatively conservative allocations. 2^48 seems like a reasonable number of interfaces to exist on a single subnet, huh? Then.... allocate 16 bits for subnetting if it must be....and call that /64 the fundamental minimum allocation. bd > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Randy Bush > Sent: Monday, April 25, 2005 3:44 PM > To: Lea Roberts > Cc: ppml at arin.net > Subject: Re: [ppml] IPv6 & /48 [was 2005-1:Business Need for > PI Assignments] > > > just to throw in a serious bomb, there is no actual real > technical reason for the /64 magic boundary. it's one of the > last big pieces of the old v6 religion. but beware that it > does have some ties to ether-like mac addresses and hence > auto-numbering. > > randy > From alh-ietf at tndh.net Wed Apr 27 13:15:20 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 27 Apr 2005 10:15:20 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <20050425164516.GA38607@ussenterprise.ufp.org> Message-ID: <20050427171527.84240145D60@smtp2.arin.net> Leo, What is absurd is making generalizations about design choices without acknowledging the trade-offs. The design point for IPv6 was 10^12 networks with 10^15 endpoints. A 64 bit space was deemed to be sufficient to accomplish that at .0001 allocation efficiency. The decisions were being made at the start of the bubble and there were concerns raised about having sufficient room to handle large levels of hierarchy to support the growing number of providers. We ended up giving the whole 64 bits to the routing function and started debating how many more to use for identifying hosts. Auto-configuration drove the choice for another 64 bits. Unfortunately we continually have to fight with the routing community because they are an extremely greedy bunch and insist that despite consolidation in the number of providers the already provided addition to more-than-enough is still not enough, also insisting that 64 bits for each lan is a waste without recognizing that there are new opportunities available by changing the per-device conservation model. It is long past time to get over it; auto-configuration requires numbers on the order of 60 bits no matter if you choose random numbers or have a central registry like the IEEE. In fact the RFID crowd wants to stuff their 96 bit thingies into an IPv6 address so one could argue that we were short sighted in giving the bits to the routing function and should really be squeezing them back down to 32 bits. In any case if routing can't do the job with 64 bits then it is time to find a new routing system. Much of the insistence on 'doing it the same as IPv4' is in fact a short-sighted approach that explicitly curtails the ability to do new things in the application space. Yes we are bad predictors of the future, but we had the foresight to not allocate the entire space up front. We are working with 1/8 of the space right now, so if the current policies prove to be insufficient over the next 50 years we have the opportunity to start over a few more times which should get us well beyond 100 years. As Geoff & David pointed out we need to do some revisiting of the H-D ratio percentage for very large providers in the short term, and that effort alone will probably get us by. We can also discuss additional recommendations like business reasons for longer than /48 to customers, but that is more to placate the business desire to differentiate services than it is to deal with any lifetime issues. The driving issue for a fixed size was to allow organizations the freedom to switch providers without having to rebuild their entire subnet plan. See http://www.ietf.org/internet-drafts/draft-hain-prefix-consider-00.txt for discussion about some longer values that would allow people to move between providers with a consistent bucket size and retain their subnet plan. This thread is about PI space. One of the things that is not discussed much is changing the overall routing model from 'everyone has to know everything' to regional knowledge. The routing community is saying they don't want a swamp, but at the same time they don't want to change anything about how they make routing decisions. The business community is saying that a provider lock is a non-starter, so we are at an impasse. The natural reaction by the RIR community is to try to find a simple metric that will allow differentiating between a global enterprise and a multi-homed consumer so explicit routing entries can be justified. We could talk about making the metric be money, but that would likely drive an even stronger push by the ITU to take over the process because governments would rightly perceive that this is a valued resource that impacts sovereign rights. Just about any other metric will cause an evaluation of need with some arbitrary and subjective outcomes. Perception of inequity is a problem where solutions tend to be political rather than technical. What we are really talking about is justifying a global routing slot. If on the other hand we defined the routing system to also allow regionally valid PI space with strict aggregation between regions, we would alleviate the majority of the issue about switching providers by allowing everyone to have PI space while containing the swamp explicit routing entries to whatever scale seemed technically appropriate. This could be done through geo-political approaches like country-code/city-code, or devoid of political context using strict geographic allocations. ISP's don't like either of these because it changes the relationships and perception of roles, but the overall result fits well with existing practice in non-IP networks. At the end of the day the point is to manage the combined routing & allocation system to keep the network functional while allowing the network consumers to get their job done. The RIR model is biased toward keeping the ISP membership happy (because that group tends to speak with a more unified voice), and therefore naturally leans toward minimizing the cost in the routing part of the problem. The business community tends to think in terms of monetary impact which ends up stirring the political pot because the historically disadvantaged see their opportunity at a level playing field being bartered away without their participation. In these discussions we walk a fine line between maintaining the status-quo as technically driven decisions and inciting a take-over by those who would make politically driven decisions. Unfortunately there is no trivial technical metric that draws a clean line in the sand about who gets to have a routing slot and who doesn't. Once you acknowledge there is no technical metric the question becomes who's political approach wins. Tony > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Leo > Bicknell > Sent: Monday, April 25, 2005 9:45 AM > To: ppml at arin.net > Subject: Re: [ppml] 2005-1:Business Need for PI Assignments > > In a message written on Mon, Apr 25, 2005 at 04:31:42PM +0100, > Michael.Dillon at radianz.com wrote: > > The question of waste has to do with the environment you are in, the > sources > > of supply, and the difficulty of obtaining a resource. IPv6 addresses > may > > Your analogy here holds more water than you might think. > > Water, like IPv6 addresses, is abundant. > > Drinkable water, like usable IPv6 addresses, is not. > > Using a /64 for a "LAN" is like dumping raw sewage into the water > and then wondering why it's contaminated. 2^32 times more than the > entire existing address space, for a single LAN. When you dump in > pollution, you prevent those downstream from using the water to > drink. Similarly, when you number a lan with a /64 you prevent > other network users from using any of those addresses, even though > you may only have 50,000 or 1,000,000 devices on your local LAN. > > Similarly, at the subnet level we have the same thing. A /48 is > 2^16 bits of subnet, or 65536 subnets. Now, I'll be the first to > admit I'd like to not have to use 1918 space for the 650 subnets I > have at home behind my 3Mbps cable modem, but giving me 100 times > that again prevents someone else from using the space who might > actually need it. > > The problem with all of this is we're extremely bad predictors of > the future. Back in the day, a /8 (16/8, to be specific) to DEC > seemed like they right thing to do, their big, they will grow. > Similarly, giving MCI a /24 (198.4.182.0/24 to be specific) in 1993 > seemed like a smart idea, they were just a small dial up e-mail > provider, after all. > > So, while the IPv6 authors are busing thinking about my 65000 subnets > at home, and my 18 quintillion hosts per subnet they are forgetting > that the most interesting things that happen in the future are the > things we can't predict now. Much as people laughed at the concept > that you would need a microprocessor in every doorknob in the 1960's, > we now regularly use them on a day to day basis in hotels and > businesses around the world. > > We have people who are talking about allocating IPv6 addresses to > serve a 60 year need. Well, that's all well and good, but it's > only 40 years after the doorknob quote and the reality is quite > different. Ideas that seem far fetched today like colonizing mars, > or faster than light travel, or nanomachines that have IP stacks > may be so common place in 60 years time that no one gives them a > second thought. > > What's most absurd about things like a /48 for cable modem users > is that it only promotes waste. Having fixed addresses is great > /but only if you can take them with you/. Well, if you can take > them with you that's an entry in the global table, which is not > what any of us want. So presumably, you won't take them with you, > which means every time you move you'll be getting new IP's. How > many people live in the same place for 60 years? Can't we use these > external events to adjust the size of the blocks given out over > time? > > While I may look like a stodgy conservative when it comes to address > space management, I'l really not. I'm pretty much a give it away > sort of guy....just on a sane scale. Let's give every home a /104 > (that is, the same amount of address space that's in a /8 today). > Further, let's go ahead and let them have 256 subnets, so it's a > /96 per house. If I'm right that this is wanton waste, we just > recovered a 48 BITS of address space. If I'm wrong, in 10 years > we can start giving out /80's to home users, 65,000 times the address > space, and still have recovered a full 32 bits of the address space. > That way when my grandchildren colonize alpha centauri and have > to number the six trillion whoiewhats that live there already they > will have plenty of space. > > In other words, let's take a bath in the water, and enjoy that it > is plentiful, but let's not dump raw sewage into the lake "because > it doesn't matter". History has a way of always making it matter. > > -- > 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 From bicknell at ufp.org Wed Apr 27 14:59:49 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 27 Apr 2005 14:59:49 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <200504271715.j3RHFTYo040627@ussenterprise.ufp.org> References: <20050425164516.GA38607@ussenterprise.ufp.org> <200504271715.j3RHFTYo040627@ussenterprise.ufp.org> Message-ID: <20050427185949.GA41864@ussenterprise.ufp.org> In a message written on Wed, Apr 27, 2005 at 10:15:20AM -0700, Tony Hain wrote: > What is absurd is making generalizations about design choices without > acknowledging the trade-offs. It's equally absurd that those who designed IPv6 to 10 year old specifications turn a deaf ear to those who've been operating networks ever since. We've learned a lot of things in the last 10 years, and many of us don't think it's inappropriate to incorporate many of them into the protocol before it's deployed. > long past time to get over it; auto-configuration requires numbers on the > order of 60 bits no matter if you choose random numbers or have a central > registry like the IEEE. In fact the RFID crowd wants to stuff their 96 bit It's statements like this that have operators tune you out completely. Autoconfiguration does not require 60 bits. AppleTalk had autoconfiguration circa 1991, with a 8 bit host space. Other failures of the protocol aside, the numbering side of things worked. In 8 bits. This is the primary problem with the operator <-> IETF interaction. More than a few times the IETF has come out with something saying "it will never work if you don't do it this way". The operators then point to it up and running on the live network, shrug, and the IETF runs back to figure out why the operators don't believe them. > thingies into an IPv6 address so one could argue that we were short sighted > in giving the bits to the routing function and should really be squeezing > them back down to 32 bits. In any case if routing can't do the job with 64 > bits then it is time to find a new routing system. One of the lessons operators learned the hard way was that one size does not fit all. Some customers can have a /29 and be happy until the end of time, others need a /6 and still want more. The other lesson the operators learned was that by the time you realize the problem it's going to be extremely painful to fix it. Indeed, the recent presentation at ARIN illustrates the problem. Potential usage for a /4 in our lifetimes. Given we had 128 bits to work with that outcome is a failure. There's no other way to describe it. Let me repeat, because this isn't a proposal to change something. If the operators do exactly what the IETF told them to do we consume a /4 in the next 50 years. Now, by your own statement, if the routing system can't do the job (consuming a /4 in the next 50 years is a failure to me) then we need a new routing system. But this is the IETF's routing system, not something the operators came up with that's already being shown to fail. > Much of the insistence on 'doing it the same as IPv4' is in fact a > short-sighted approach that explicitly curtails the ability to do new things > in the application space. Yes we are bad predictors of the future, but we More addresses do not allow you to "do new things in the application space". This is snake oil being sold by the IETF. I have yet to see even a single conceptual idea for IPv6 that cannot be done over IPv4, much less one with working code. From AppleTalk to IPX to DECNet to XNS to IP the applications have stayed the same, and have not cared one iota about address size. The exact details of how the protocol works may change slightly, in some cases, but the majority of applications don't care. One of the smart things smart people did years ago was to layer things. The application, up at layer 7, doesn't really care what the layer 3 network does. Indeed, with a well written application I can run telnet from my freebsd box over IP, XNS, or AppleTalk, and the application doesn't even know the difference. It's all stuffed in a library. The only way IPv6 "enables new applications" is via more address space. I can't number all the grains of sand in the world today, so an application that depends on talking to all of them doesn't work. More addresses make it work. > had the foresight to not allocate the entire space up front. We are working > with 1/8 of the space right now, so if the current policies prove to be > insufficient over the next 50 years we have the opportunity to start over a > few more times which should get us well beyond 100 years. As Geoff & David That's short sighted. IPv4 is going to last at least 40 years in the end, probably more like 50. Given the rate at which we learn I think it's not unreasonable to expect an order of magnitude improvement. That means we should be looking at a 400 to 500 year timeframe. The computing industry and our knowledge grow exponentially, not linearly. > lifetime issues. The driving issue for a fixed size was to allow > organizations the freedom to switch providers without having to rebuild > their entire subnet plan. See I don't know anyone who redoes thier subnet plans today when they renumber. Perhaps that used to occur, but today if someone comes to me as a provider and says they have 12 subnets and want to renumber into my space, I give them, imagine this, 12 subnets. I don't see why the same thing couldn't happen in IPv6. If someone had 12 IPv6 subnets and came to me I would give them 12 new subnets. If any renumbering occurred in the past it was due to gross ineffiency in their numbering plan. That's been worked out and we're going into V6 with our eyes wide open. The idea that an ISP would say "oh, you had 12 subnets at your old provider, so we're only going to give you 6" is absurd. As long as they don't get in trouble with an RIR an ISP will do whatever it can to make a customer happy, after all they are paying the bills. > This thread is about PI space. One of the things that is not discussed much > is changing the overall routing model from 'everyone has to know everything' > to regional knowledge. The routing community is saying they don't want a > swamp, but at the same time they don't want to change anything about how > they make routing decisions. The business community is saying that a Well, I don't know about others. I'm willing to change, but let me start with something the IETF needs to learn. Networks are not regional. Networks are not regional. Networks are not regional. Networks are not regional. Networks are not regional. Networks are not regional. Networks are not regional. It is possible to have a regional network. The great firewall of China and everything behind it is a good example. However that is very much the exception and not the rule. Businesses are actually worse on this point than ISP's. The fact of the matter is that network traffic crosses boarders for reasons that have nothing to do with geopolitical boundaries, but all about economics. What's worse is that these parameters change on a daily basis. @home went from the top of it's game to nothing. Cogent built a business out of stitching together a lot of smaller networks. Asian countries sent all their bits to the US and back for a long time, only recently building local exchanges. The whole reason the Internet works today is that it is adaptable. Partial routes, full routes, peering here but not there, transit, partial transit, they all serve a place. While I don't know what would be the best way to "upgrade" the routing system, I know some things that don't work. The first of them is any expectation that a power heirachy will stay in place for any length of time is dead wrong. We've got 5,000 years of recorded history to prove that. So building a heirarchial routing system won't work. Please stop trying. > context using strict geographic allocations. ISP's don't like either of > these because it changes the relationships and perception of roles, but the > overall result fits well with existing practice in non-IP networks. I note that all the other existing networks are being phased out and moved over IP networks at an ever increasing rate. Frame, ATM, Circuits, Telephony, they are all moving over IP packet based networks. While some of the other schemes worked well for a while, in the end they will be replaced by something better. > driven decisions. Unfortunately there is no trivial technical metric that > draws a clean line in the sand about who gets to have a routing slot and who > doesn't. Once you acknowledge there is no technical metric the question > becomes who's political approach wins. Who gets a routing slot is not a technical question. It has an upper bounds defined by a technical limitation (how many routes can the system support), but inside that technical limitation it is a political and economic problem. Given that it is political and economic, and that the IETF is full of technical people, I recommend they stop trying to "solve" that problem. Maybe the IETF has some grand vision of the future they haven't been able to articulate. That said, the operator community is smart, and from where I sit is looking at IPv6 and laughing. The emperor has no clothes. It's IPv4 with bigger addresses, nothing more, nothing less. When you have college educated people who have 15 years experience running networks looking at the proposal and going "that doesn't make a lot of sense" something is seriously wrong. -- 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 alh-ietf at tndh.net Wed Apr 27 17:43:34 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 27 Apr 2005 14:43:34 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <20050427185949.GA41864@ussenterprise.ufp.org> Message-ID: <20050427214340.17D90145C1F@smtp2.arin.net> Leo Bicknell wrote: > In a message written on Wed, Apr 27, 2005 at 10:15:20AM -0700, Tony Hain > wrote: > > What is absurd is making generalizations about design choices without > > acknowledging the trade-offs. > > It's equally absurd that those who designed IPv6 to 10 year old > specifications turn a deaf ear to those who've been operating > networks ever since. We've learned a lot of things in the last 10 > years, and many of us don't think it's inappropriate to incorporate > many of them into the protocol before it's deployed. No, you haven't learned, but it is reasonable to make adjustments prior to wide-scale deployment. > > > long past time to get over it; auto-configuration requires numbers on > the > > order of 60 bits no matter if you choose random numbers or have a > central > > registry like the IEEE. In fact the RFID crowd wants to stuff their 96 > bit > > It's statements like this that have operators tune you out completely. > Autoconfiguration does not require 60 bits. AppleTalk had > autoconfiguration circa 1991, with a 8 bit host space. Other > failures of the protocol aside, the numbering side of things worked. > In 8 bits. For a small number of devices per segment, and with massive issues involving collisions when segments partitioned and reconnected. I would not want to reconstruct the number of hours I personally wasted dealing with AppleTalk failures, and it was a third order protocol used by a few admins at the time. > > This is the primary problem with the operator <-> IETF interaction. > More than a few times the IETF has come out with something saying > "it will never work if you don't do it this way". The operators > then point to it up and running on the live network, shrug, and the > IETF runs back to figure out why the operators don't believe them. The major problem is that the current crop of operators generally believes they have all operational knowledge and that if 'we only keep doing it the way we already know' thing will work fine. Some of us burned a lot of late hours migrating a collection of random protocols to IPv4 and learned the hard way that some approaches are just bad ideas. > > > thingies into an IPv6 address so one could argue that we were short > sighted > > in giving the bits to the routing function and should really be > squeezing > > them back down to 32 bits. In any case if routing can't do the job with > 64 > > bits then it is time to find a new routing system. > > One of the lessons operators learned the hard way was that one size > does not fit all. Some customers can have a /29 and be happy until > the end of time, others need a /6 and still want more. Yes, but the IETF was looking at the operators that were insisting on /128's per customer and noting that this would lead to another NAT disaster. /48 is technically sufficient even if it is more than many will need. > > The other lesson the operators learned was that by the time you > realize the problem it's going to be extremely painful to fix it. But they refuse to acknowledge that doing something different than past practice creates a different set of problems that are equally painful to fix. > > Indeed, the recent presentation at ARIN illustrates the problem. > Potential usage for a /4 in our lifetimes. Given we had 128 bits to > work with that outcome is a failure. There's no other way to describe > it. On the contrary it is not a failure; it says we hit the mark. We are working from a /3 and even if we missed by 2x by 2050 we are still within the design goal. That said, it is still reasonable to change the H-D metric for large providers so we are not pushing that limit. > > Let me repeat, because this isn't a proposal to change something. > > If the operators do exactly what the IETF told them to do we consume a > /4 in the next 50 years. > > Now, by your own statement, if the routing system can't do the job > (consuming a /4 in the next 50 years is a failure to me) then we need > a new routing system. But this is the IETF's routing system, not > something the operators came up with that's already being shown to > fail. That is just wrong. The existing system was developed to the requirements of the providers and through RIR allocation policies continues to be driven by the providers. The IETF said there is no technical justification for longer than a /48, and that the issue about switching providers is something that is important yet the ISPs consider that less desirable because they like provider locking. > > > Much of the insistence on 'doing it the same as IPv4' is in fact a > > short-sighted approach that explicitly curtails the ability to do new > things > > in the application space. Yes we are bad predictors of the future, but > we > > More addresses do not allow you to "do new things in the application > space". This is snake oil being sold by the IETF. I have yet to > see even a single conceptual idea for IPv6 that cannot be done over > IPv4, much less one with working code. From AppleTalk to IPX to > DECNet to XNS to IP the applications have stayed the same, and have > not cared one iota about address size. All of your examples are limited address space protocols where the node is only given a single address. Look simply at XP and you will find that the stack has an address for inbound connections and another random number for use by the web browser to avoid privacy issues from web site tracking tools. This is working code and it is being discussed for other applications like voip to do what many pbxs do today by assigning a central 'from' string so that return calls don't go directly to the employee's desk. > > The exact details of how the protocol works may change slightly, > in some cases, but the majority of applications don't care. One > of the smart things smart people did years ago was to layer things. > The application, up at layer 7, doesn't really care what the layer > 3 network does. Indeed, with a well written application I can run > telnet from my freebsd box over IP, XNS, or AppleTalk, and the > application doesn't even know the difference. It's all stuffed in > a library. You make light of 'well written'. Too many app developers think they are smarter than the stack and reach down to grab details rather than use the available abstraction. Yes people can build apps that don't care, but if apps were really protocol agnostic it would not be such a big deal to do something as trivial as switch versions of IP. > > The only way IPv6 "enables new applications" is via more address > space. I can't number all the grains of sand in the world today, > so an application that depends on talking to all of them doesn't > work. More addresses make it work. This is an example of the closed mindedness that leads to precluding innovation. Yes IPv6 provides more addresses. One use of trivial multiple addresses per interface would be to allow a multi-function server to have independent addresses per app so that the ephemeral port ranges could be shared and firewall configuration could be simplified. Yes that can be and is done in IPv4, but to a limited degree due to the limited addresses available. Another use might be application limitations based on the cryptographic authenticity of an address, which requires a substantial number of bits. Yet another use would be to build auto-configuring consumer routers that support a wide range of link technologies. The point is we don't know what might be possible because everything to date has had a limited number of bits to work with for identifying hosts on a segment. Rather than force a continuation of that by insisting on unnecessary conservation, read your own comments above and realize that even 44 bits is sufficient for the public routing system as we know it without any changes. > > > had the foresight to not allocate the entire space up front. We are > working > > with 1/8 of the space right now, so if the current policies prove to be > > insufficient over the next 50 years we have the opportunity to start > over a > > few more times which should get us well beyond 100 years. As Geoff & > David > > That's short sighted. IPv4 is going to last at least 40 years in > the end, probably more like 50. Given the rate at which we learn > I think it's not unreasonable to expect an order of magnitude > improvement. That means we should be looking at a 400 to 500 year > timeframe. The computing industry and our knowledge grow exponentially, > not linearly. > The last IPv4 address will never be issued because either nobody will care, or nobody will be able to afford it. Given that we are arguing about the lifetime of 1/8th of IPv6 being 50 or 100 years, the 400 to 800 numbers don't see out of line, even if we do nothing. We are likely to change the H-D ratio for large providers so this whole discussion goes away. > > lifetime issues. The driving issue for a fixed size was to allow > > organizations the freedom to switch providers without having to rebuild > > their entire subnet plan. See > > I don't know anyone who redoes thier subnet plans today when they > renumber. Perhaps that used to occur, but today if someone comes > to me as a provider and says they have 12 subnets and want to > renumber into my space, I give them, imagine this, 12 subnets. So if someone gets a /12 from an ISP that only has a /12 then moves to your network you will also give them a /12? This sounds like a business opportunity to be in the position of transient address space allocator. > > I don't see why the same thing couldn't happen in IPv6. If someone > had 12 IPv6 subnets and came to me I would give them 12 new subnets. > If any renumbering occurred in the past it was due to gross ineffiency > in their numbering plan. That's been worked out and we're going > into V6 with our eyes wide open. You are thinking about larger organizations that have technical knowledge and the ability to describe their network. If a consumer came to you with an auto-configuring router and no concept of IP subnets what would you say? Since multi-media bridging is an even more brain-dead idea than nat, you would need to know if they had power-line, 1394, or any newer non-Ethernet based media attached to the device. What if the attachment CPE were a cell phone and the device behind it was a car? How many subnets would an auto manufacturer build into the chassis? How would a consumer know? The point is you don't need to preclude those environments because you have more than enough space to allow them without pre-biasing the system against their potential deployment. > > The idea that an ISP would say "oh, you had 12 subnets at your old > provider, so we're only going to give you 6" is absurd. As long > as they don't get in trouble with an RIR an ISP will do whatever > it can to make a customer happy, after all they are paying the > bills. It is not absurd if you don't happen to agree with the other provider on the interpretation of the RIR policy. > > > This thread is about PI space. One of the things that is not discussed > much > > is changing the overall routing model from 'everyone has to know > everything' > > to regional knowledge. The routing community is saying they don't want a > > swamp, but at the same time they don't want to change anything about how > > they make routing decisions. The business community is saying that a > > Well, I don't know about others. I'm willing to change, but let me > start with something the IETF needs to learn. > > Networks are not regional. > Networks are not regional. > Networks are not regional. > Networks are not regional. > Networks are not regional. > Networks are not regional. > Networks are not regional. Political edicts mean traditional IP topologies are irrelevant. Political edicts mean traditional IP topologies are irrelevant. Political edicts mean traditional IP topologies are irrelevant. Political edicts mean traditional IP topologies are irrelevant. Political edicts mean traditional IP topologies are irrelevant. Political edicts mean traditional IP topologies are irrelevant. We don't have any yet, but they are looming. This is not an IETF driven thing. The IETF is about defining standard approaches to the problems of the day. Yes they go off the rails from time to time and try to tell people how to run their networks, but in general all they do is tell vendors how to build products that will interoperate and solve the operator problems. > > It is possible to have a regional network. The great firewall of > China and everything behind it is a good example. However that is > very much the exception and not the rule. Businesses are actually > worse on this point than ISP's. The fact of the matter is that > network traffic crosses boarders for reasons that have nothing to > do with geopolitical boundaries, but all about economics. Governments have the ability to change the economics if they choose to. So far the Internet has been left to run free reign, but the economic powers in the traditional telecom world are putting pressure on their governments to fix that problem. All it would take is for major businesses to insist that the ISPs are being unreasonable in this strict topology aggregation approach and there would be a significant shift in Internet economics. > > What's worse is that these parameters change on a daily basis. > @home went from the top of it's game to nothing. Cogent built a > business out of stitching together a lot of smaller networks. Asian > countries sent all their bits to the US and back for a long time, > only recently building local exchanges. These are all lightweight from the perspective of the ITU. Exchanges and political number-plan aggregation are a well understood business practice as are bypass arrangements. Things can be done differently than the traditional RIR/ISP address management model and still be operationally viable. They will not scale in the same ways but they can be made to work. From a political perspective that is all that matters. > > The whole reason the Internet works today is that it is adaptable. > Partial routes, full routes, peering here but not there, transit, > partial transit, they all serve a place. While I don't know what > would be the best way to "upgrade" the routing system, I know some > things that don't work. The first of them is any expectation that > a power heirachy will stay in place for any length of time is dead > wrong. We've got 5,000 years of recorded history to prove that. > So building a heirarchial routing system won't work. Please stop > trying. The existing hierarchy model is by the insistence of the ISPs. Routing protocol stability and memory management have been paramount in leading us to where we are. This is not some edict from elsewhere, it is homegrown. The reason you have the options you do today is that I for one insisted that there was not a 'single core' network that everyone else defaulted to. We were doing warped things with EGP and early BGP that lead to the array of routing knobs you take for granted today. I actually don't thing that BGP itself is all that broken. What is broken is the perception that we need strict provider based aggregation to scale. I need to refresh it in the IETF directory but http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-07.txt shows an approach (and there are others based on geo-political regions) that allows distribution of the PI deaggregated noise by using exchange points to realign topology. Yes current business practice routes around exchanges for the most part. If that were the only path for enterprises to acquire PI space though, I suspect the drive for PI would win out and force some rerouting of topology to fit. Yes this is an economics game, but there are many more parameters than simply what is the shortest fiber path. Given a choice between provider-lock/renumbering-pain vs. a little bit more for a diverted fiber run, I am sure businesses would favor the known cost of fiber over the unknown and potentially lethal costs of yielding to the provider. > > > context using strict geographic allocations. ISP's don't like either of > > these because it changes the relationships and perception of roles, but > the > > overall result fits well with existing practice in non-IP networks. > > I note that all the other existing networks are being phased out > and moved over IP networks at an ever increasing rate. Frame, ATM, > Circuits, Telephony, they are all moving over IP packet based > networks. While some of the other schemes worked well for a while, > in the end they will be replaced by something better. As will IPv6. I have no illusions that IPv6 will actually exhaust the space, because there will be some other reason to replace it long before that happens. It is a good protocol, but it is not the end of protocol development. > > > driven decisions. Unfortunately there is no trivial technical metric > that > > draws a clean line in the sand about who gets to have a routing slot and > who > > doesn't. Once you acknowledge there is no technical metric the question > > becomes who's political approach wins. > > Who gets a routing slot is not a technical question. It has an > upper bounds defined by a technical limitation (how many routes can > the system support), but inside that technical limitation it is a > political and economic problem. Given that it is political and > economic, and that the IETF is full of technical people, I recommend > they stop trying to "solve" that problem. The IETF is not trying to solve the problem, the RIR's are. The proposal at the recent ARIN meeting was to use possession of an AS number as the technical metric for a routing slot. Unfortunately that metric only requires that you have connections to more than one provider. There is a vast difference between number of connections and need for a routing slot. > > Maybe the IETF has some grand vision of the future they haven't > been able to articulate. That said, the operator community is > smart, and from where I sit is looking at IPv6 and laughing. The > emperor has no clothes. It's IPv4 with bigger addresses, nothing > more, nothing less. When you have college educated people who have > 15 years experience running networks looking at the proposal and > going "that doesn't make a lot of sense" something is seriously > wrong. What you have is a bunch of self-appointed demi-gods claiming they know how networks work when all they really know is the IPv4 Internet they inherited. They believe that because things developed a specific way in IPv4 that we really should or even need to continue that for all possible network deployments in the future. They specifically refuse to step outside their closed box and realize that there are alternatives that were not possible in the past. In particular explicit management of device addresses by providers is a historical artifact of telephony, X.25, F/R, ATM, and IPv4 where businesses could buy a large enough block to do their own thing but the average person could not. In the network connected appliance environment we are heading into you as a service provider should not want to deal with every power cycle event on every consumer appliance at the customer prem. You should not care how many different media technologies they deploy (implying number of subnets) as long as they pay their bills. It will be easier and cheaper for everyone if ISP just stop trying to micro-manage their customers. This only forces masking technologies like nat because the customer in the end will not put up with it. The Internet was built by tunneling over the telco's that refused to provide the applications and services that the innovators around the edge were creating. Innovators can and will tunnel over brain-dead ISPs that try to restrict the freedom of the edge networks in the future. There is no technical reason to be more conservative with IPv6 addresses than we already are, but there may be business differentiation reasons for longer prefixes, which leads to a need to standardize some smaller buckets so that we avoid problems when people switch providers. Tony From bicknell at ufp.org Wed Apr 27 19:06:55 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 27 Apr 2005 19:06:55 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <200504272143.j3RLhbuB051814@ussenterprise.ufp.org> References: <20050427185949.GA41864@ussenterprise.ufp.org> <200504272143.j3RLhbuB051814@ussenterprise.ufp.org> Message-ID: <20050427230655.GB53824@ussenterprise.ufp.org> In a message written on Wed, Apr 27, 2005 at 02:43:34PM -0700, Tony Hain wrote: > What you have is a bunch of self-appointed demi-gods claiming they know how > networks work when all they really know is the IPv4 Internet they inherited. Wow. -- 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 Michael.Dillon at radianz.com Thu Apr 28 06:04:19 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 28 Apr 2005 11:04:19 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <20050427171527.84240145D60@smtp2.arin.net> Message-ID: > Yes we are bad predictors of the future, but we > had the foresight to not allocate the entire space up front. We are working > with 1/8 of the space right now, so if the current policies prove to be > insufficient over the next 50 years we have the opportunity to start over a > few more times which should get us well beyond 100 years. > If on the other hand we defined the routing system to also allow regionally > valid PI space with strict aggregation between regions, we would alleviate > the majority of the issue about switching providers by allowing everyone to > have PI space while containing the swamp explicit routing entries to > whatever scale seemed technically appropriate. This could be done through > geo-political approaches like country-code/city-code, or devoid of political > context using strict geographic allocations. In the end, I think that strict geographic allocations which follow the topology of the network, are the only workable solution. However, in order to make this work, we need some solid analysis of demand distribution (current and potential) in order to design the distribution of these geographical addresses. And we also need people to recognize that this is not about drawing boundaries. A network topology doesn't have boundaries, it has centers of connectedness that are the equivalent of real-world cities and towns. Since we do have the space available to do geographic addressing by using another 1/8th of the IPv6 address space, why are we not seriously pursuing this avenue? I know that geopolitical addressing is sexier, i.e. the same old, same old, but if we had some serious work being done on geographical addressing that would be sufficient to push the geopolitical ideas to the bottom of the agenda. > The RIR model is biased toward keeping the > ISP membership happy (because that group tends to speak with a more unified > voice), and therefore naturally leans toward minimizing the cost in the > routing part of the problem. The RIR model is also a form of ad-hoc geographical addressing. Unfortunately, the RIR model does not follow through with the details required to make geographical addressing work at all levels of the network. --Michael Dillon From Michael.Dillon at radianz.com Thu Apr 28 06:13:05 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 28 Apr 2005 11:13:05 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <20050427185949.GA41864@ussenterprise.ufp.org> Message-ID: > It's IPv4 with bigger addresses, nothing > more, nothing less. I think you need to read a book on IPv6 and how it works. You may not believe that the IPv6 delivers value beyond the bigger addresses however it is not true to say that IPv6 is nothing more than IPv4 with bigger addresses. > When you have college educated people who have > 15 years experience running networks looking at the proposal and > going "that doesn't make a lot of sense" something is seriously > wrong. I remember when hundreds of college educated telecom engineers looked at IPv4 and said, "that doesn't make a lot of sense, ATM is the future". Imagine how things would be if the ATM forum was in charge of making ARIN policy... --Michael Dillon From stephen at sprunk.org Thu Apr 28 07:36:55 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 28 Apr 2005 06:36:55 -0500 (CDT) Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: <20050427171527.84240145D60@smtp2.arin.net> Message-ID: <57552.198.23.26.254.1114688215.squirrel@www.dfw.nostrum.com> Michael.Dillon at radianz.com said: > In the end, I think that strict geographic allocations which > follow the topology of the network, are the only workable solution. Make up your mind -- do you want strict geographic allocations or do you want addressing that follows topology? Those are only the same thing for very simple end user scenarios. Real world example: picture an enterprise with 40,000 sites in the US. Should each of those sites be numbered from the local state/city pool? Should they be numbered from the nearest public Internet connection? What if a site in MT is connected to the Internet via four same-company hubs in LA, NY, Hong Kong, and Brussels? Please explain how _any_ addressing model other than PI makes sense. > Since we do have the space available to do geographic addressing > by using another 1/8th of the IPv6 address space, why are we not > seriously pursuing this avenue? I know that geopolitical addressing > is sexier, i.e. the same old, same old, but if we had some serious > work being done on geographical addressing that would be sufficient > to push the geopolitical ideas to the bottom of the agenda. The reason it's not being pursued is that (a) the topology does not follow geography today and (b) providers have motivation to make it so. It'd make for a nice Ph.D. thesis though. S From tvest at pch.net Thu Apr 28 07:57:27 2005 From: tvest at pch.net (Tom Vest) Date: Thu, 28 Apr 2005 13:57:27 +0200 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <57552.198.23.26.254.1114688215.squirrel@www.dfw.nostrum.com> References: <20050427171527.84240145D60@smtp2.arin.net> <57552.198.23.26.254.1114688215.squirrel@www.dfw.nostrum.com> Message-ID: <0eddae55bae2157febc9b7fcc9f3ed0d@pch.net> On Apr 28, 2005, at 1:36 PM, Stephen Sprunk wrote: > Michael.Dillon at radianz.com said: >> In the end, I think that strict geographic allocations which >> follow the topology of the network, are the only workable solution. > > Make up your mind -- do you want strict geographic allocations or do > you > want addressing that follows topology? Those are only the same thing > for > very simple end user scenarios. > > Real world example: picture an enterprise with 40,000 sites in the US. > Should each of those sites be numbered from the local state/city pool? > Should they be numbered from the nearest public Internet connection? > What > if a site in MT is connected to the Internet via four same-company > hubs in > LA, NY, Hong Kong, and Brussels? Please explain how _any_ addressing > model other than PI makes sense. > >> Since we do have the space available to do geographic addressing >> by using another 1/8th of the IPv6 address space, why are we not >> seriously pursuing this avenue? I know that geopolitical addressing >> is sexier, i.e. the same old, same old, but if we had some serious >> work being done on geographical addressing that would be sufficient >> to push the geopolitical ideas to the bottom of the agenda. > > The reason it's not being pursued is that (a) the topology does not > follow > geography today and (b) providers have motivation to make it so. > > It'd make for a nice Ph.D. thesis though. > > S I categorically disagree. It would make for a terrible Ph.D. thesis. Tom From Michael.Dillon at radianz.com Thu Apr 28 08:30:22 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 28 Apr 2005 13:30:22 +0100 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <57552.198.23.26.254.1114688215.squirrel@www.dfw.nostrum.com> Message-ID: > > In the end, I think that strict geographic allocations which > > follow the topology of the network, are the only workable solution. > > Make up your mind -- do you want strict geographic allocations or do you > want addressing that follows topology? Those are only the same thing for > very simple end user scenarios. I want strict geographic allocations that follow the geography of the network. This is roughly similar to real-world geography except that the distance between cities is not measured in straight lines because the fiber routes are not straight lines. An analogy from the real-world is the underground metro system in many countries. There are published maps which clearly show the geography of the train lines connecting the various stations. However, one cannot determine the physical distance between stations, even on the same line, because the map shows the network geography and not the physical geography. Nevertheless, you can look at a metro map for Moscow or London and determine whether a station is in the east or the west of the city, whether it is near the center or far from the center. > Real world example: picture an enterprise with 40,000 sites in the US. > Should each of those sites be numbered from the local state/city pool? Should? I'm talking about "may" here. I want us to allocate geographic addressing so that they MAY number each site from their local city pool or they MAY number each site according to some other plan. I want to create a situation in which the existing IPv6 address allocation plan has to compete in the real world with a geographic addressing plan. In the end, both systems may be successful because I believe that smaller networks will prefer to use geographic addresses. This will take enough pressure off the global routing table so that larger enterprises can continue to use the current 2000::/3 addressing plan and announce their own global routes. > Please explain how _any_ addressing > model other than PI makes sense. Simple. The current PI addressing model requires an organization to announce routes globally in order to obtain multihomed resilience. The PI addressing model does not necessarily provide a way in which such route announcements can be aggregated, thus the current PI addressing model cannot accomodate exponential growth in multihoming. Since a geographic addressing model does provide for planned aggregation at city and regional and continental levels, it can accomodate exponential growth in multihoming when the multihomed organization buys services from two or more ISPs in their city who support geographical addressing. > The reason it's not being pursued is that (a) the topology does not follow > geography today and (b) providers have motivation to make it so. Topology does follow geography. So do a lot of other things. The network exists in the real world. Obviously, one can pick nits with the fact that all fiber lines do not exactly follow major highways, railways and sea lanes. But that is irrelevant. The fact is that communications traffic broadly follows the same pathways as real-world commercial traffic. New York is well connected in both economic and network terms. > It'd make for a nice Ph.D. thesis though. I'm not so sure there is a Ph.D. thesis in this but there is certainly a Masters level project or two. It would be nice to see the results of some serious studies on the issue. And it would be really nice if the RIRs would, at least partially, fund some research in this area. --Michael Dillon From owen at delong.com Thu Apr 28 16:57:34 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Apr 2005 13:57:34 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: > In the end, I think that strict geographic allocations which > follow the topology of the network, are the only workable solution. Except that the topology of the network does not follow strict geographic lines. > Since we do have the space available to do geographic addressing > by using another 1/8th of the IPv6 address space, why are we not > seriously pursuing this avenue? I know that geopolitical addressing > is sexier, i.e. the same old, same old, but if we had some serious > work being done on geographical addressing that would be sufficient > to push the geopolitical ideas to the bottom of the agenda. > Because there apparently aren't enough people who are convinced that this model reflects reality. 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 Thu Apr 28 17:09:06 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Apr 2005 14:09:06 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: References: Message-ID: <161DFD0283CB496140B7F367@imac-en0.delong.sj.ca.us> Can we please not choose another rathole for this proposal? Anonymous, if you want to create a geographic addressing proposal, write up a policy proposal and submit it. This isn't that. This is about PI space for organizations that need it. Currently, I think determination of need along the lines of having an AS (if you qualify for an AS, generally, you're going to need a prefix to advertise), but, there seems to be some desire to modify that criteria. So, can we please refocus the discussion on what it would take to get consensus around PI policy for organizations that need it in the V6 world? Thanks, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From gih at apnic.net Thu Apr 28 17:41:17 2005 From: gih at apnic.net (Geoff Huston) Date: Fri, 29 Apr 2005 07:41:17 +1000 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <57552.198.23.26.254.1114688215.squirrel@www.dfw.nostrum.co m> References: <20050427171527.84240145D60@smtp2.arin.net> <57552.198.23.26.254.1114688215.squirrel@www.dfw.nostrum.com> Message-ID: <6.0.1.1.2.20050429073536.03a7ed70@kahuna.telstra.net> > > Since we do have the space available to do geographic addressing > > by using another 1/8th of the IPv6 address space, why are we not > > seriously pursuing this avenue? I know that geopolitical addressing > > is sexier, i.e. the same old, same old, but if we had some serious > > work being done on geographical addressing that would be sufficient > > to push the geopolitical ideas to the bottom of the agenda. It would appear that you either have to provide a radically different routing paradigm that can carry a large amount of fine-grained detail, or you have to provide a radically different inter-provider settlement regime and a coupled QoS regime that commoditises packet transit, so that all possible paths have indistinguishable performance characteristics. [btw, the latter is effectively what happened in the multi-provider PSTN] A longer version of this comment is at http://www.potaroo.net/ispcol/2004-12/index.html if you are interested regards, Geoff From david.conrad at nominum.com Thu Apr 28 17:43:58 2005 From: david.conrad at nominum.com (David Conrad) Date: Thu, 28 Apr 2005 14:43:58 -0700 Subject: [ppml] YAGAvPBAFF (was: 2005-1:Business Need for PI Assignments) In-Reply-To: References: Message-ID: <90256751e64a185c8e78cc567d2793fe@nominum.com> [Yet Another Geographic Addressing vs. Provider Based Addressing Food Fight, in case you were wondering] Michael, On Apr 28, 2005, at 5:30 AM, Michael.Dillon at radianz.com wrote: > Since a geographic addressing model does provide for planned > aggregation > at city and regional and continental levels, it can accomodate > exponential > growth in multihoming when the multihomed organization buys services > from two or more ISPs in their city who support geographical > addressing. As I understand it, one of the traditional difficulties with this model is that it would require, in order to make business sense, the equivalent of PSTN-style settlements to deal with transit issues. While this approach would definitely be favored by the ITU and many PTTs, I'm not sure anyone else is particularly interested in recreating the settlements model. Is this not an issue? As an aside, I'm probably too cynical, but I have a sneaking suspicion this is one of the reasons the ITU is pushing national based allocations. > Topology does follow geography. No it doesn't. Physical topology does (sort of by definition), but telecommunications network topology follows economics and politics which sometimes follow geography. Until fairly recently, the topology of the Asia Pacific region was a star with the US in the center because in general it was cheaper to go through the US to send intra-AP region traffic than it was to link AP region countries directly. I remember when two universities in Thailand which were no more than a few miles from each other exchanged traffic via Falls Church, VA. The situation is better now, but there are still cases where folks in, e.g., one African country prefer to transit Europe to reach another African country. If bandwidth on fiber going from NY to LA via Kodiak Island becomes cheaper than fiber going from NY to LA via Kansas City, I don't believe the network topology will follow geography. Rgds, -drc From kloch at hotnic.net Thu Apr 28 17:56:32 2005 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 28 Apr 2005 17:56:32 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <161DFD0283CB496140B7F367@imac-en0.delong.sj.ca.us> References: <161DFD0283CB496140B7F367@imac-en0.delong.sj.ca.us> Message-ID: <42715C10.3040902@hotnic.net> Owen DeLong wrote: > Can we please not choose another rathole for this proposal? > > Anonymous, if you want to create a geographic addressing proposal, write > up a policy proposal and submit it. > Likewise if someone wants to change the /48 or /64 boundaries, I'd like to see the proposal. In either case 2005-1 automatically tracks changes in end site policy so it has no effect on the merits of 2005-1. > This isn't that. This is about PI space for organizations that need > it. Currently, I think determination of need along the lines of > having an AS (if you qualify for an AS, generally, you're going to > need a prefix to advertise), but, there seems to be some desire > to modify that criteria. What did you think of the "mini-LIR" idea? - Kevin From stephen at sprunk.org Thu Apr 28 07:56:04 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 28 Apr 2005 06:56:04 -0500 Subject: [ppml] 2005-1:Multi-national Business Enablement References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> <025801c548d9$260aeb00$6601a8c0@stephen> <20050425222956.GA20348@srv01.cluenet.de> Message-ID: <000401c54cc3$b2553730$6501a8c0@ssprunk> Thus spake "Daniel Roesen" > On Sun, Apr 24, 2005 at 09:13:48AM -0500, Stephen Sprunk wrote: > > > Nope. They should get a /48 unless they can convincingly show that > > > they'll never need more than a single subnet. > > > > It is ridiculous to think that ISPs are going to completely discard their > > current IPv4 topology to deploy IPv6. > > Why must they discard any topology? IPv6 mandates a particular topology and disallows others which happen to be in widespread use by IPv4 ISPs. If a provider using the latter were to offer IPv6, they would need to change their IPv4 topology as well, and I have trouble seeing ARIN approving an ISP quadrupling (or more) their IPv4 requirements so they'd have an IPv6-compliant topology. > They might have problems to charge for /48 instead of /64 if /48 > becomes "usual" at the competitors, yeah. But that's primarily a > business thing. Not what I was talking about. > > Most "residential" ISPs I'm aware of use a single subnet for N customers, > > Hm? I guess you are referring to cable modem stuff? It's common for cable, DSL, wireless, and other technologies. For instance, my landlord provides a straight ethernet connection into my residence (which is connected to a T1); with DHCP, I consume only one IP per PC. For them to offer me an IPv6 /48 or even /64, they'd need to change their IPv4 addressing to a /30 or shorter for each customer, wasting four addresses for a customer with one PC. > Over here (DE), almost all residential users use dial-up, be it real > (analog, ISDN) or virtual (DSL, via PPPoE). So they are connected via > virtual interfaces, and get their IP address usually via dynamic pools > or static via RADIUS. No problem adapting this to assign /48s > (especially via RADIUS). If that's the topology, then that makes sense. However, it's not the dominant topology in the US today. > > and that is perfectly reasonable to continue with IPv6 -- just assign > > a /64. That allows customers to put as many hosts as they want on the > > "bare" connection, and any who want their own subnet(s) can be issued > > a /64 or /48 of their own > > And then charged additional install and monthly fee? Cool. We want to > get rid of this as much as possible. Artificial scarcity sucks. In IPv4, > there is the perceived scarcity excuse for ISPs. Don't recreate that in > IPv6, thanks. Compare to the artificial scarcity of IPv6 addresses created by (a) no PI space being available, and (b) not allowing assignment of IPv6 addreses with existing topologies. Frankly, it costs less to deliver a single /64 to N customers than to deliver N /64s or /48s to N customers. If there's a price difference, so be it -- as long as both are available. Choice is good. > The mantra is "/48, no questions asked, and by default". When you consider how that affects the IPv4 topology, that doesn't make sense in many cases. If we're going to share subnets across customers in IPv4, we need to do the same for IPv6. 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 jeroen at unfix.org Fri Apr 29 10:58:21 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 29 Apr 2005 16:58:21 +0200 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: <000401c54cc3$b2553730$6501a8c0@ssprunk> References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> <025801c548d9$260aeb00$6601a8c0@stephen> <20050425222956.GA20348@srv01.cluenet.de> <000401c54cc3$b2553730$6501a8c0@ssprunk> Message-ID: <1114786701.19419.50.camel@firenze.zurich.ibm.com> On Thu, 2005-04-28 at 06:56 -0500, Stephen Sprunk wrote: > > > Most "residential" ISPs I'm aware of use a single subnet for N > customers, > > > > Hm? I guess you are referring to cable modem stuff? > > It's common for cable, DSL, wireless, and other technologies. For instance, > my landlord provides a straight ethernet connection into my residence (which > is connected to a T1); with DHCP, I consume only one IP per PC. The "end-site" in this case is your building, as such the building gets the /48 and your landlord divides this /48 into chunks, a /64 per ethernet. In the future your landlord could then install multiple ethernet lines or other L2's, maybe wireless and use any of the other 65k /64's on those L2's. > For them to > offer me an IPv6 /48 or even /64, they'd need to change their IPv4 > addressing to a /30 or shorter for each customer, wasting four addresses for > a customer with one PC. You don't have multiple segments in your house, and if you do then your landlord could give you either a separate /48 or he would give you a couple of /64's to toy around with. "End-site" should be seen where 'administrative control' is separated. You quite apparently are just a user of a network (in this case at least ;) and not the admin. Which goes in line with the fact that if you would have a number of networks in your own house, then your landlord would become an "ISP" and he would give you a /48 as the admin changes for that network. Though for the coming n years a /48 for the building you live in should be fine (or does your place look like one of those ubersized villa's? :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From david.conrad at nominum.com Fri Apr 29 18:56:39 2005 From: david.conrad at nominum.com (David Conrad) Date: Fri, 29 Apr 2005 15:56:39 -0700 Subject: PI vs. PA, the Sequel (was [ppml] 2005-1:Business Need for PI Assignments) In-Reply-To: <20050427214340.17D90145C1F@smtp2.arin.net> References: <20050427214340.17D90145C1F@smtp2.arin.net> Message-ID: <71b62a468e225b382acf96b7191b0ea1@nominum.com> Tony, I am speaking only for myself. I most assuredly not representing Nominum or anyone else. Use at your own risk. Void where prohibited. Use protective eye wear. Do not eat. May cause cancer in rats. Do not use near open flame. I didn't do it! On Apr 27, 2005, at 2:43 PM, Tony Hain wrote: >> More than a few times the IETF has come out with something saying >> "it will never work if you don't do it this way". The operators >> then point to it up and running on the live network, shrug, and the >> IETF runs back to figure out why the operators don't believe them. > The major problem is that the current crop of operators generally > believes > they have all operational knowledge and that if 'we only keep doing it > the > way we already know' thing will work fine. I suspect this sort of dialog isn't particularly productive. > Yes, but the IETF was looking at the operators that were insisting on > /128's > per customer and noting that this would lead to another NAT disaster. Ignoring value judgments on tools, the fact that IPv6 uses the same routing technology as IPv4 means, at least to me, that the address allocation models should be similar. As we (Internet users in general) have learned, sometimes painfully, that having fixed values can bite you in the butt, it seems prudent to pro-actively apply some amount of bug repellant. All we are arguing about is how much. > That is just wrong. The existing system was developed to the > requirements of > the providers In as much as the providers were interested in keeping their routers from falling over, I guess you could say this. However, non-providers were intimately involved in many of the discussions that resulted in RFC 2050 so characterizing the existing system as you have is incorrect. An attempt was made to document existing allocation practice to take into account the requirements of both end users and providers. The fact that IPv4 allocation policy can be viewed as skewed toward providers is likely due to the fact that emphasis was placed on not overloading the routing system as that was seen as in the best interests of the most entities. > and through RIR allocation policies continues to be driven by > the providers. Just to be clear, RIR policies are defined via a documented (and followed) open policy process. Anyone, provider or not, can submit policy proposals and be involved in discussions to drive a particular policy or derail it as your conscience and/or technical understanding dictates. > The IETF said there is no technical justification for longer > than a /48, And 640K will always be enough. As will 32 bits. I have a bit of difficulty with assertions such as these as history is littered with cases where the presumed near-limitless turned out to be quite limiting. 48 is, as far as I know, an arbitrary number with a few pleasing binary properties. Why not 50? Why not 46? Why not 32? It has even more pleasing binary properties. The point is, the fact that the number is arbitrary and has changed over time does not give me warm fuzzies that it is the One True Limit on how long a prefix needs to be. > and that the issue about switching providers is something that > is important yet the ISPs consider that less desirable because they > like > provider locking. I'm not sure I follow how allocating longer prefixes would enable provider locking if everyone is following the same allocation policy. Lock-in and lock-in avoidance techniques such as NAT occur because people have to renumber if they change providers. > The point is we > don't know what might be possible because everything to date has had a > limited number of bits to work with for identifying hosts on a segment. IPv6 still provides a limited number of bits. Many more, but still a limited number. I agree that we don't know what might be possible, however I believe one of the arguments is that because we don't know, we should be somewhat conservative in allocations. Particularly given IPv6 is using the same routing technology as has resulted in unpleasant surprises regarding scalability. > The last IPv4 address will never be issued because either nobody will > care, > or nobody will be able to afford it. As an aside, while I agree that the last IPv4 address won't be allocated, I suspect that will be because a market will establish itself for IPv4 addresses and people with vast tracts of address space will find that maybe NAT isn't so bad after all, particularly when they can sell the addresses they aren't using. > Given that we are arguing about the > lifetime of 1/8th of IPv6 being 50 or 100 years, Err, no. The estimates Geoff came up with were for all 48 bits. When we said a /1 to a /4, we were talking about one half to one sixteenth of all the address space, not just the 1/8th in use now. > Political edicts mean traditional IP topologies are irrelevant. Very true. I personally do not think the alternative topologies preferred by the PTT/ITU community are desirable. Obviously others differ. > This is not an IETF driven thing. Not driven perhaps, but the IETF has made the highway. In IPv4 aggregation is the one way we know how to scale networked systems. Provider-based aggregation is the approach that has evolved to be economically viable. Since the IETF chose a protocol that was a simplification and minor (well, except for bits) extension of IPv4, in particularly continuing to use the existing routing technologies without specifying the promised renumbering technology to remove the most significant downsides, it can be argued that the IETF has set the stage for political edicts. > Governments have the ability to change the economics if they choose > to. So > far the Internet has been left to run free reign, but the economic > powers in > the traditional telecom world are putting pressure on their > governments to > fix that problem. I agree. I also believe one sure way to get governments involved is to create an environment where there is a perceived risk that a country won't be able to get the IPv6 addresses they need. Another is to give the impression of egregiously mismanaging a critical resource. I suspect if you asked someone on the street if they thought reducing 340282366920938463463374607431768211456 possible items to 281474976710656 items was egregious mismanagement, they'd probably agree. > The IETF is not trying to solve the problem, the RIR's are. The > proposal at > the recent ARIN meeting was to use possession of an AS number as the > technical metric for a routing slot. Unfortunately that metric only > requires > that you have connections to more than one provider. There is a vast > difference between number of connections and need for a routing slot. I believe the intent of AS based proposals is that generally, an AS signifies (or is supposed to signify) a network topologically significant set of prefixes as opposed to leaf nodes. As I'm sure you know, topologically significant sets of networks can have different routing policies than their parents/peers so they require a routing slot to be used optimally. On the other hand, a leaf node must have the same (or a subset of the) routing policy as their parent, thus their routing announcement can be subsumed by their parent. As such, using an AS as an indicator of the need for a provider independent prefix would seem to make sense. You can argue that everyone needs a provider independent prefix, but if you do, it would probably be helpful to describe in technical detail how the routing system with such an allocation policy can be made to scale. Since we know the current approach works and given the importance of keeping the system working, I believe the burden is on those who would propose to change the system to demonstrate convincingly that the new system would work. In any event, I suspect it would be appreciated by most if we could ratchet down the assumption of evil intent or stupidity on the part of one ambiguous group or another. Rgds, -drc From stephen at sprunk.org Sat Apr 30 18:47:02 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 30 Apr 2005 17:47:02 -0500 Subject: [ppml] 2005-1:Business Need for PI Assignments References: Message-ID: <01f901c54deb$443478f0$6601a8c0@stephen> Thus spake > > > In the end, I think that strict geographic allocations which > > > follow the topology of the network, are the only workable > > > solution. > > > > Make up your mind -- do you want strict geographic allocations > > or do you want addressing that follows topology? Those are > > only the same thing for very simple end user scenarios. > > I want strict geographic allocations that follow the geography of the > network. This is roughly similar to real-world geography except that > the distance between cities is not measured in straight lines because > the fiber routes are not straight lines. The topology of the network rarely follows geography. Both ISPs and enterprises tend to have many, many sites that are not connected to exchanges or private peering/transit to every other provider in that location. For a concrete example, say each state is given a geographical registry (extrapolate to national or continental levels instead if desired). A provider in Detroit may reasonably choose to get its connectivity solely from Chicago and Cleveland. Either (a) the provider uses Illinois or Ohio addresses, meaning their customers can only multihome (or change providers) to other providers also serving Illinois and Ohio, or (b) the provider uses Michigan addresses and must announce more-specifics into the global (or at least US) routing tables for each customer block. Both scenarios are worse than what we have today. The only way to make this work is to force providers (by law) to peer with or purchase transit from all other providers in a given location to be allowed to offer service there. I can't help but think the economic effects of this would be far, far worse than what we suffer with today, nor have I seen any studies of these problems by the various folks proposing geographic addressing. > > Real world example: picture an enterprise with 40,000 sites in > > the US. Should each of those sites be numbered from the local > > state/city pool? > > Should? I'm talking about "may" here. I want us to allocate > geographic addressing so that they MAY number each site from > their local city pool or they MAY number each site according to > some other plan. I want to create a situation in which the > existing IPv6 address allocation plan has to compete in the > real world with a geographic addressing plan. Unfortunately, many others proposing the same addressing model are planning to use it to replace, not augment, the current model. > > The reason it's not being pursued is that (a) the topology does > > not follow geography today and (b) providers have [no] > > motivation to make it so. > > Topology does follow geography. No, it does not. The vast, vast majority of networks I personally have worked on have little if any correlation to geography at the IP level. Geographic addressing makes things simpler for sites that are connected only to other sites in the same area, and that may be nice for consumers and some businesses, but it makes things worse for operators of more complicated networks. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov