From michael.dillon at bt.com Mon Feb 5 03:48:09 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 Feb 2007 08:48:09 -0000 Subject: [ppml] IPv4 address exhaustion policy Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C1C04C08@i2km07-ukbr.domain1.systemhost.net> Some folks in APNIC are proposing an IPv4 exhaustion policy which can be read here: http://www.apnic.net/docs/policy/discussions/prop-046-v001.txt The document contains language that suggests they will attempt to ram the same policy through ARIN and other RIRs since they seem to think that IPv4 exhaustion must be managed with one global coordinated policy. Even a quick read of the policy shows flaws such as the ridiculous assumption that if IPv4 addresses are not available, people will use IPv6 instead. This may in fact be true in the APNIC region, but I suspect that in the ARIN region this will lead to increased use of NAT and "borrowed" address ranges such as DOD stuff. One objectional proposal is that IANA should hold "some" /8 blocks in reserve, thus bringing the exhaustion event to an earlier date. Another problem is that they suggest delaying policy to deal with recycling addresses. Since recycling addresses will mitigate the problem of exhaustion, this again attempts to create a crisis earlier than it would naturally occur. My position is that IANA should do nothing new. When they have given up the last available /8, that's it. After that it is up to the RIRs to manage their allocations. The only area where IANA might do something different is to encourage the DOD to give back their allocations that they don't use on the public network. ARIN's main job is to come up with a clear and public policy on address recycling similar to that used by the telephony network. If you cease to use a telephone number, the network operator will hold it unused for a certain period of time, and then reissue it to another subscriber. ARIN should have a similar recycling policy for IPv4 addresses. --Michael Dillon From owen at delong.com Mon Feb 5 04:01:31 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 5 Feb 2007 01:01:31 -0800 Subject: [ppml] IPv4 address exhaustion policy In-Reply-To: <2DA00C5A2146FB41ABDB3E9FCEBC74C1C04C08@i2km07-ukbr.domain1.systemhost.net> References: <2DA00C5A2146FB41ABDB3E9FCEBC74C1C04C08@i2km07-ukbr.domain1.systemhost.net> Message-ID: <1C9C617D-3A34-49DC-AEC3-03D63C7E4C41@delong.com> > they don't use on the public network. ARIN's main job is to come up > with > a clear and public policy on address recycling similar to that used by > the telephony network. If you cease to use a telephone number, the > network operator will hold it unused for a certain period of time, and > then reissue it to another subscriber. ARIN should have a similar > recycling policy for IPv4 addresses. > The problem with that theory is that ARIN isn't TPC, it's more like NANPA. NANPA doesn't assign end-telephone numbers, they just assign AC and Prefixes (much like ARIN). To make matters even more complicated, with the advent of LNP (which we will eventually need to address in IP, no matter how much the aggregation crowd wants to pretend otherwise), phone numbers move around independent of their original NANPA block assignments. Where ARIN differs from NANPA is that ARIN also issues some direct assignments (which, to the best of my knowledge, end- subscribers can't get NANPA NPA-NXX assignments) in addition to Allocations to LIR/ISPs (which more resemble the NANPA services). i agree that ARIN should start considering policy for post-exhaustion management of the address space, but, I don't think that a TPC style reclamation process quite fits the bill. For one thing, what mechanism would you use to determine an address was no longer in use? Would you use different methods for post-ARIN allocations/assignments vs. pre-ARIN legacy assignments in the ARIN region? If so, what would you do for each of those cases? Owen From michael.dillon at bt.com Mon Feb 5 04:22:51 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 Feb 2007 09:22:51 -0000 Subject: [ppml] IPv4 address exhaustion policy Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C1C04CCF@i2km07-ukbr.domain1.systemhost.net> > > they don't use on the public network. ARIN's main job is to > come up > > with > > a clear and public policy on address recycling similar to > that used by > > the telephony network. If you cease to use a telephone number, the > > network operator will hold it unused for a certain period > of time, and > > then reissue it to another subscriber. ARIN should have a similar > > recycling policy for IPv4 addresses. > > > The problem with that theory is that ARIN isn't TPC, it's more like > NANPA. > NANPA doesn't assign end-telephone numbers, they just assign > AC and Prefixes (much like ARIN). However, NANPA policy does have rules about how number recycling is done such as how long an address can be held back before reuse. I'm not suggesting that we mirror NANPA policies, just that we are not the only people having to deal with this type of policy issue. > i agree that ARIN should start considering policy for post-exhaustion > management of the address space, but, I don't think that a TPC > style reclamation process quite fits the bill. Well, if it only fits the bill a little bit, then perhaps it is a good starting point to work from. > For one thing, what mechanism would you use to determine an > address was no longer in use? Would you use different methods > for post-ARIN allocations/assignments vs. pre-ARIN legacy > assignments in the ARIN region? If so, what would you do for > each of those cases? Good questions. --Michael Dillon From tme at multicasttech.com Mon Feb 5 09:45:14 2007 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 5 Feb 2007 09:45:14 -0500 Subject: [ppml] IPv4 address exhaustion policy In-Reply-To: <1C9C617D-3A34-49DC-AEC3-03D63C7E4C41@delong.com> References: <2DA00C5A2146FB41ABDB3E9FCEBC74C1C04C08@i2km07-ukbr.domain1.systemhost.net> <1C9C617D-3A34-49DC-AEC3-03D63C7E4C41@delong.com> Message-ID: <98DB1ED7-CEBF-40CE-A532-016DE6676212@multicasttech.com> Hello; On Feb 5, 2007, at 4:01 AM, Owen DeLong wrote: >> they don't use on the public network. ARIN's main job is to come up >> with >> a clear and public policy on address recycling similar to that >> used by >> the telephony network. If you cease to use a telephone number, the >> network operator will hold it unused for a certain period of time, >> and >> then reissue it to another subscriber. ARIN should have a similar >> recycling policy for IPv4 addresses. >> > The problem with that theory is that ARIN isn't TPC, it's more like > NANPA. > NANPA doesn't assign end-telephone numbers, they just assign > AC and Prefixes (much like ARIN). To make matters even more > complicated, with the advent of LNP (which we will eventually need > to address in IP, no matter how much the aggregation crowd wants > to pretend otherwise), phone numbers move around independent > of their original NANPA block assignments. > > Where ARIN differs from NANPA is that ARIN also issues some > direct assignments (which, to the best of my knowledge, end- > subscribers can't get NANPA NPA-NXX assignments) in addition > to Allocations to LIR/ISPs (which more resemble the NANPA > services). > > i agree that ARIN should start considering policy for post-exhaustion > management of the address space, but, I don't think that a TPC > style reclamation process quite fits the bill. > > For one thing, what mechanism would you use to determine an > address was no longer in use? Would you use different methods > for post-ARIN allocations/assignments vs. pre-ARIN legacy > assignments in the ARIN region? If so, what would you do for > each of those cases? > The only safe mechanism I could see is that they are not paying the bill, which the RIR could tell them. The RIR could send out termination notices, wait a decent amount of time and inform IANA. But, how is this different from now ? After all, it says right in the ARIN policy manual 4.2.1.2. Annual Renewal An annual fee for registered space is due by the anniversary date of the ISP's first allocation from ARIN. ISPs should take care to ensure that their annual renewal payment is made by their anniversary due date in accordance with the Registration Services Agreement. If not paid by the anniversary date, the address space may be revoked. Please review the Annual Renewal/Maintenance Fees Page for more details. So, it's not clear to me that any action is actually needed here. For pre-ARIN assignments, you could check for the bankruptcy of the original assignee, but that would not necessary be safe (companies may die without going bankrupt, and, of course, successor entities routinely pick up such assets). What you could do, although this will not be politically popular I suspect, is to start raising the fees or the burden to get space as exhaustion nears, and then provide a discount / rebate / easier assignment for companies that recover lost space. In other words, put the burden on the people that want the space. Suppose that if you could show that - an address block was owned by a bankrupt or defunct entity and - it had not been advertised since the bankruptcy or for the past year, whichever is longest and - efforts to contact the former assignees were fruitless, including at least some effort by ARIN or - the previous assignees or their successors had signed a quitclaim deed. then, you could get the space. As it gets harder or more expensive to get "new" space, this would become more attractive. Regards Marshall > Owen > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Crumb_Anthony_A at cat.com Mon Feb 5 10:13:29 2007 From: Crumb_Anthony_A at cat.com (Anthony A. Crumb) Date: Mon, 5 Feb 2007 09:13:29 -0600 Subject: [ppml] IPv4 address exhaustion policy In-Reply-To: <2DA00C5A2146FB41ABDB3E9FCEBC74C1C04C08@i2km07-ukbr.domain1.systemhost.net> Message-ID: ppml-bounces at arin.net wrote on 02/05/2007 02:48:09 AM: > To > To > > > > > Some folks in APNIC are proposing an IPv4 exhaustion policy which can be > read here: > http://www.apnic.net/docs/policy/discussions/prop-046-v001.txt > > The document contains language that suggests they will attempt to ram > the same policy through ARIN and other RIRs since they seem to think > that IPv4 exhaustion must be managed with one global coordinated policy. > Even a quick read of the policy shows flaws such as the ridiculous > assumption that if IPv4 addresses are not available, people will use > IPv6 instead. This may in fact be true in the APNIC region, but I > suspect that in the ARIN region this will lead to increased use of NAT > and "borrowed" address ranges such as DOD stuff. > > One objectional proposal is that IANA should hold "some" /8 blocks in > reserve, thus bringing the exhaustion event to an earlier date. Another > problem is that they suggest delaying policy to deal with recycling > addresses. Since recycling addresses will mitigate the problem of > exhaustion, this again attempts to create a crisis earlier than it would > naturally occur. > > My position is that IANA should do nothing new. When they have given up > the last available /8, that's it. After that it is up to the RIRs to > manage their allocations. The only area where IANA might do something > different is to encourage the DOD to give back their allocations that > they don't use on the public network. ARIN's main job is to come up with > a clear and public policy on address recycling similar to that used by > the telephony network. If you cease to use a telephone number, the > network operator will hold it unused for a certain period of time, and > then reissue it to another subscriber. ARIN should have a similar > recycling policy for IPv4 addresses. I agree that forcing early exhaustion of IPv4 space seems to be misguided and that IANA should continue its existing address allocation policy. While reclamation of unused or under used allocations might lend some relief, I think determining what methodology to employ would be very problematic. Simple utilization scans would show only space that is deployed in direct Internet facing, unprotected network environments and would not show space that is being utilized in tiered DMZ, internal server farms, dealer - supplier - client - and military business partner Extranet environments. Many organization have deployed public address space in these areas to avoid address collisions with business partners,and they do not wish to directly expose their server farms to the internet. I am sure it is common for a public address allocation to have substantial use within an organization while exposing only a small portion of the space to the Internet. How would utilization rates of allocated address space be determined? Great discussion topic, thanks for sharing --Tony Crumb > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich at nic.umass.edu Mon Feb 5 10:26:08 2007 From: rich at nic.umass.edu (Rich Emmings) Date: Mon, 5 Feb 2007 10:26:08 -0500 (EST) Subject: [ppml] IPv4 address exhaustion policy In-Reply-To: <2DA00C5A2146FB41ABDB3E9FCEBC74C1C04C08@i2km07-ukbr.domain1.systemhost.net> References: <2DA00C5A2146FB41ABDB3E9FCEBC74C1C04C08@i2km07-ukbr.domain1.systemhost.net> Message-ID: Adoption of this policy would probably cause a run on address space and "conservation" of existing space by existing holders, rather than a return. On Mon, 5 Feb 2007, michael.dillon at bt.com wrote: > Some folks in APNIC are proposing an IPv4 exhaustion policy which can be > read here: > http://www.apnic.net/docs/policy/discussions/prop-046-v001.txt > From OWEN at delong.com Fri Feb 9 03:53:20 2007 From: OWEN at delong.com (Owen DeLong) Date: Fri, 9 Feb 2007 00:53:20 -0800 Subject: [ppml] Diving before ARIN San Juan Message-ID: I know this isn't exactly policy related, but, I don't know of a better way to suggest this to likely attendees. If you're not considering attending the next ARIN meeting, disregard this altogether. If you are, then, I'd like to see how many people may be interested in SCUBA diving at least one, possibly both weekend days before the meeting. San Juan is rated in the top 5 for Beach Dives. There are also boat dives that involve full-day trips to more distant dive sites off the East Coast or Fajardo. I have not been to PR before, but, I am looking forward to diving there. I have not made any definite plans, but, if there's enough interest, I'll try and put something together. If you are not a certified diver, but, would like to try this, don't hesitate to express interest. This can easily be accomodated. If you are interested, please send me the following information: 1. Your name 2. Your prefered contact email address 3a. Are you a certified diver. 3b. If yes, what level (SCUBA diver, Open Water Diver, Advanced Open Water, etc.) 4. Will you be bringing your own equipment? (If yes, indicate anything besides tanks and weights you will need. If No, then, I know what you'll need (everything)) 5. If you have any preference on dates, dive sites, etc. Please express it. 6. If you are certified Divemaster/DiveCon or above and are currently insured, would you be willing to take a leadership role in the dives? I will tally up results I receive between now and Feb. 20th. If there's enough interest, I'll build a mailing list of interested participants and send you data as it becomes available. If there is not sufficient interest, I'll send out a notification to that effect, and, will let people who did express interest know what plans I make for myself and invite them to join if possible. A bit about me as a diver... I'm a PADI Assistant Instructor and a Master SCUBA diver. My diving includes more than 300 dives in various waters around the world. Most of my diving is cold-water (Monterey and Southern California), which is among the most challenging recreational diving in the world. I also have tropical experience in fresh and salt water around the pacific and Florida. Owen From info at arin.net Sat Feb 10 08:47:32 2007 From: info at arin.net (Member Services) Date: Sat, 10 Feb 2007 08:47:32 -0500 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Information from NRPM Message-ID: <45CDCCF4.6040008@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Removal of Ipv6 Operational Information from NRPM Authors: Lea Roberts Cathy Aronson Proposal Version: Version 0 Submission Date: 8 February 2007 Proposal type: Modify Policy term: Permanent Policy statement: The following parts of Section 6.5.4.1 should be removed from the Number Resource Policy Manual (NRPM). NRPM Section 6.5.4.1 states: The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites Rationale: Discussions in recent public policy meetings, as well as in Advisory Council meetings, have led to the consensus that operational information, such as these IPv6 guidelines, should be removed from the NRPM. This section is a clear example of text not directly related to ARIN policy and so it is proposed that it should be removed. Timetable for implementation: Immediate From owen at delong.com Sat Feb 10 14:19:26 2007 From: owen at delong.com (Owen DeLong) Date: Sat, 10 Feb 2007 11:19:26 -0800 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Information from NRPM In-Reply-To: <45CDCCF4.6040008@arin.net> References: <45CDCCF4.6040008@arin.net> Message-ID: I support this policy. Owen On Feb 10, 2007, at 5:47 AM, Member Services wrote: > ARIN received the following policy proposal. In accordance with the > ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being > placed on > ARIN's website. > > The AC will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is presented; > > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, > > 3. Not accept the proposal as a formal policy proposal. > > The AC will review this proposal at their next meeting. If the AC > accepts the proposal, then it will be posted as a formal policy > proposal > to PPML and it will be presented at a Public Policy Meeting. If the AC > does not accept the proposal, then the AC will explain that decision; > and at that time the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Removal of Ipv6 Operational Information from > NRPM > > Authors: > Lea Roberts > Cathy Aronson > > Proposal Version: Version 0 > > Submission Date: 8 February 2007 > > Proposal type: Modify > > Policy term: Permanent > > Policy statement: > > The following parts of Section 6.5.4.1 should be removed from the > Number Resource Policy Manual (NRPM). > > NRPM Section 6.5.4.1 states: > > The following guidelines may be useful (but they are only > guidelines): > > * /64 when it is known that one and only one subnet is needed > > * /56 for small sites, those expected to need only a few subnets > over the next 5 years. > > * /48 for larger sites > > Rationale: > > Discussions in recent public policy meetings, as well as in Advisory > Council meetings, have led to the consensus that operational > information, such as these IPv6 guidelines, should be removed from the > NRPM. This section is a clear example of text not directly related to > ARIN policy and so it is proposed that it should be removed. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From christopher.morrow at gmail.com Tue Feb 13 13:54:18 2007 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 13 Feb 2007 13:54:18 -0500 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Information from NRPM In-Reply-To: <75cb24520702121434v60bf2cd3x8031e1df59738fda@mail.gmail.com> References: <45CDCCF4.6040008@arin.net> <75cb24520702121434v60bf2cd3x8031e1df59738fda@mail.gmail.com> Message-ID: <75cb24520702131054j109e0840l6b01a883cec3605b@mail.gmail.com> Yes, let us abolish the classful nature of addressing. -chris > > On 2/10/07, Member Services wrote: > > Policy Proposal Name: Removal of Ipv6 Operational Information from NRPM From info at arin.net Thu Feb 15 10:00:42 2007 From: info at arin.net (Member Services) Date: Thu, 15 Feb 2007 10:00:42 -0500 Subject: [ppml] Deadline for Policy Proposals - 22 February 2007 Message-ID: <45D4759A.7070200@arin.net> The ARIN XIX Public Policy Meeting will take place 23-24 April 2007 in San Juan, Puerto Rico. New policy proposals must be submitted by 23:59 EST, 22 February 2007, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XIX agenda. This is in accordance with ARIN's Internet Resource Policy Evaluation Process, which requires that proposed policies be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing policies must submit a Policy Proposal Template. The template must be sent via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Thu Feb 15 10:08:45 2007 From: info at arin.net (Member Services) Date: Thu, 15 Feb 2007 10:08:45 -0500 Subject: [ppml] Policy Proposal: IPv4 PI minimum size change Message-ID: <45D4777D.4070407@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 PI minimum size change Author: David Williamson Proposal Version: 1.0 Submission Date: 2/14/2007 Proposal type: modify Policy term: permanent Policy statement: In section 4.3.2.2 of the NRPM, change all occurences of "/22" to "/24". (That is, replace the existing 4.3.2.2 with this text: For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose. Remove references to IPv4 in section 4.4, as they are no longer relevant. Section 4.4 could be moved, at the discretion of the NRPM editors, to somewhere in section 6, for clarity. Rationale: The rationale for moving the allocation "edge" for IPv4 PI space to /24 has three fundamental points: routing slot consumption would be unchanged, it reflects widespread routing practices, and it discourages waste. While experiments indicate that a few ISPs still try to filter at the /22 boundary, I have been repeatedly told that most don't filter anything shorter than a /24. While routing policy and allocation policies don't need to necessarily match, it is not unreasonable to have them in alignment. In addition, by keeping the PI allocation size for multi-homed organizations at /22, organizations seeking PI space that don't meet the requirements may be encouraged to exaggerate their address usage. This is something that should clearly not be encouraged. On the topic of routing slots, I would like to note that any org qualifying under the PI policies in 4.3.2.2 would also qualify for PA space, and would likely have an interest in multi-homing regardless of the usage of PA vs. PI space. In either instance, a routing slot is consumed by a /24. This policy change should therefore have minimal, if any, impact on the size of the global routing table. It merely gives organizations more options at a slightly smaller network size. Remember that for consideration under 4.3.2.2, an organiztion *must* be multi-homed. On a side note, it's tempting to remove the restriction entirely. If an organization only qualifies for a /28 (for example), they could receive an allocation of that size. Market forces would decide if that /28 was worth a routing slot. If the /28 contained my personal website, I suspect it would not be routable. If that /28 contained Microsoft Update, I suspect it would. In the interest of operational sanity and simplicity, I am not making a proposal to remove the restriction. (Note that section 4.1.1 explicitly notes that PI addresses are not guaranteed to be globally routable.) There is fundamental conflict between the urge for aggregation and the desire for conservation. The latter would prefer that organizations not have any excess space, while the former would prefer that fewer networks exist in the DFZ, regardless of wastage. Since the DFZ already permits deaggregation to /24, the conservation urge should be allowed to push to that edge. As noted in 4.1.5, "determination of IP address allocation size is the responsibility of ARIN." This proposal simply allows the community to request appropriately sized blocks, and ARIN to allocate prefixes of a size that is commensurate with established need. Timetable for implementation: immediate From owen at delong.com Thu Feb 15 12:08:20 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 15 Feb 2007 09:08:20 -0800 Subject: [ppml] Policy Proposal: IPv4 PI minimum size change In-Reply-To: <45D4777D.4070407@arin.net> References: <45D4777D.4070407@arin.net> Message-ID: I support this policy. As an additional point of consideration, APNIC will issue a PI /24 under the same criteria, so, this is not incompatible with what is happening in other parts of the world. I was not able to find a minimum assignment size in the RIPE documentation. LACNIC minimum assignment size is also /24. AfriNIC appears not to support direct assignments as such, and I was not able to identify a minimum allocation unit in their policies. However, I do know that before AfriNIC went operational, when the original 2002-3 was being discussed, AfriNICs constituency proposed 2003-15 to get an ARIN policy specific to what would become the AfriNIC region allowing the assignment of /24 addresses. Between David's rather compelling arguments about routing table entries and the situation with the other RIRs policies, I think it is time to move the ARIN direct assignment boundary to /24. Owen From packetgrrl at gmail.com Thu Feb 15 17:33:42 2007 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 15 Feb 2007 15:33:42 -0700 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Information from NRPM In-Reply-To: <45CDCCF4.6040008@arin.net> References: <45CDCCF4.6040008@arin.net> Message-ID: Hi everyone, I would like to have some discussion here about this. For the time being I have withdrawn this proposal. The reason is that it seems that the information that it strikes is information that the ARIN staff uses to help guide LIRs to assign reasonable blocks to their customers. When an LIR assigns /40s to each of its customers just because, ARIN can point to the guidelines as to what more reasonable assignments are. It is pretty much a given that this information needs to exist somewhere but it's not quite policy. I'd like your thoughts about this. One idea is to have a document that's like the NRPM but contains operational guidelines for LIRs. Maybe like an NPOG (Number Policy Operational Guidelines). Thanks! ----Cathy On 2/10/07, Member Services wrote: > > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The AC will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is presented; > > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, > > 3. Not accept the proposal as a formal policy proposal. > > The AC will review this proposal at their next meeting. If the AC > accepts the proposal, then it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. If the AC > does not accept the proposal, then the AC will explain that decision; > and at that time the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Removal of Ipv6 Operational Information from NRPM > > Authors: > Lea Roberts > Cathy Aronson > > Proposal Version: Version 0 > > Submission Date: 8 February 2007 > > Proposal type: Modify > > Policy term: Permanent > > Policy statement: > > The following parts of Section 6.5.4.1 should be removed from the > Number Resource Policy Manual (NRPM). > > NRPM Section 6.5.4.1 states: > > The following guidelines may be useful (but they are only > guidelines): > > * /64 when it is known that one and only one subnet is needed > > * /56 for small sites, those expected to need only a few subnets > over the next 5 years. > > * /48 for larger sites > > Rationale: > > Discussions in recent public policy meetings, as well as in Advisory > Council meetings, have led to the consensus that operational > information, such as these IPv6 guidelines, should be removed from the > NRPM. This section is a clear example of text not directly related to > ARIN policy and so it is proposed that it should be removed. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Feb 15 18:49:50 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 15 Feb 2007 15:49:50 -0800 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Information from NRPM In-Reply-To: References: <45CDCCF4.6040008@arin.net> Message-ID: <810D18C7-3BF2-4D8E-8320-1FB14CD3829C@delong.com> Shouldn't this go in an RFC similar to RFC 2050? Owen On Feb 15, 2007, at 2:33 PM, cja at daydream.com wrote: > Hi everyone, > > I would like to have some discussion here about this. For the > time being I have withdrawn this proposal. The reason is that it > seems that the information that it strikes is information that the > ARIN staff uses to help guide LIRs to assign reasonable blocks to > their customers. When an LIR assigns /40s to each of its customers > just because, ARIN can point to the guidelines as to what more > reasonable assignments are. It is pretty much a given that this > information needs to exist somewhere but it's not quite policy. > I'd like your thoughts about this. > > One idea is to have a document that's like the NRPM but contains > operational guidelines for LIRs. Maybe like an NPOG (Number Policy > Operational Guidelines). > From Daniel_Alexander at Cable.Comcast.com Thu Feb 15 22:33:21 2007 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Thu, 15 Feb 2007 22:33:21 -0500 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM References: <45CDCCF4.6040008@arin.net> Message-ID: <2271C950731A734680BA3E2978816F1808B69116@NJCHLEXCMB01.cable.comcast.com> This discussion seems to play along the same lines as the policy proposal to remove the multiple /48 requirement. Both of these skirt around the extent of an RIR's control. One thought is "These statements should be removed." This is because ARIN should not be mandating what an ISP/LIR can allocate to it's users. Even if it wanted to, it has little ability to enforce such a statement, so why try and take this stance. Once an ISP/LIR obtains an allocation, they can allocate in whatever way they feel is necessary. ARIN's main recourse to enforce responsible use is the initial and subsequent allocation requirements. Trying to make these kinds of demands gives ARIN an intrusive image it can't control. The other thought is "These statements should remain." This is because ARIN needs some mechanism to provide direction, in response to organizations seeking guidance, on how to allocate responsibly, and what is expected of them. It is not an issue that the information is in there, but where in the NRPM it is placed. By having the statement in section 6.5.4 it leans towards the first approach, trying to define how an ISP/LIR should service it's customers. Policies should not be written to dictate how an ISP/LIR should conduct it's business, but rather how the Internet community should use resources in a responsible manner. I agree that the proposed wording in 6.5.4.1 should be removed. I agree that the proposed wording in section 6.5.4.2 should be removed. The problem is, in the absence of a clear initial and subsequent allocation requirement, ARIN would be left with nothing to prevent irresponsible practices. This is a very subtle difference but seems to be where many proposals run into issues. As a result, these statements should remain as guidelines, until the community is comfortable with the development of the surrounding IPv6 policies. My two cents, Dan ________________________________ From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of cja at daydream.com Sent: Thursday, February 15, 2007 5:34 PM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM Hi everyone, I would like to have some discussion here about this. For the time being I have withdrawn this proposal. The reason is that it seems that the information that it strikes is information that the ARIN staff uses to help guide LIRs to assign reasonable blocks to their customers. When an LIR assigns /40s to each of its customers just because, ARIN can point to the guidelines as to what more reasonable assignments are. It is pretty much a given that this information needs to exist somewhere but it's not quite policy. I'd like your thoughts about this. One idea is to have a document that's like the NRPM but contains operational guidelines for LIRs. Maybe like an NPOG (Number Policy Operational Guidelines). Thanks! ----Cathy On 2/10/07, Member Services wrote: ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Removal of Ipv6 Operational Information from NRPM Authors: Lea Roberts Cathy Aronson Proposal Version: Version 0 Submission Date: 8 February 2007 Proposal type: Modify Policy term: Permanent Policy statement: The following parts of Section 6.5.4.1 should be removed from the Number Resource Policy Manual (NRPM). NRPM Section 6.5.4.1 states: The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites Rationale: Discussions in recent public policy meetings, as well as in Advisory Council meetings, have led to the consensus that operational information, such as these IPv6 guidelines, should be removed from the NRPM. This section is a clear example of text not directly related to ARIN policy and so it is proposed that it should be removed. Timetable for implementation: Immediate _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Thu Feb 15 23:54:54 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 15 Feb 2007 20:54:54 -0800 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM In-Reply-To: <2271C950731A734680BA3E2978816F1808B69116@NJCHLEXCMB01.cable.comcast.com> References: <45CDCCF4.6040008@arin.net> <2271C950731A734680BA3E2978816F1808B69116@NJCHLEXCMB01.cable.comcast.com> Message-ID: <85F8E6FA-90D4-4805-BDC9-43E454571E48@delong.com> I think that the root problem is that the RIR and ASO have policy as their only tool. What I believe is needed is an additional tool. If we add a "recommendation" tool, then, we have the NRPM for Policy, and the "recommendation repository" for recommendations. Policy should not dictate how an ISP/LIR operates it's business. However, Best common practices and other recommendations could be collected in such a "recommendations repository" as a community resource without carrying the force or appearance of policy, thus removing the confusion. So, perhaps what is needed is a (rather large) policy proposal that does the following: 1. Create the "recommendations repository" (please, come up with a better name for it). 2. Remove all such recommendations from the NRPM. 3. Add a section to the NRPM stating that non-binding recommendations are retained in the repository and that the NRPM is strictly for binding policies regarding resource allocations. 4. Define a procedure for the updating of the "recommendations repository", probably much like the IRPEP, or, extend the IRPEP to allow it to encompass the creation/modification of such recommendations. 5. Whatever other steps I missed in this process. Owen On Feb 15, 2007, at 7:33 PM, Alexander, Daniel wrote: > > This discussion seems to play along the same lines as the policy > proposal to remove the multiple /48 requirement. Both of these skirt > around the extent of an RIR's control. > > One thought is "These statements should be removed." This is because > ARIN should not be mandating what an ISP/LIR can allocate to it's > users. > Even if it wanted to, it has little ability to enforce such a > statement, > so why try and take this stance. Once an ISP/LIR obtains an > allocation, > they can allocate in whatever way they feel is necessary. ARIN's main > recourse to enforce responsible use is the initial and subsequent > allocation requirements. Trying to make these kinds of demands gives > ARIN an intrusive image it can't control. > > The other thought is "These statements should remain." This is because > ARIN needs some mechanism to provide direction, in response to > organizations seeking guidance, on how to allocate responsibly, and > what > is expected of them. > > It is not an issue that the information is in there, but where in the > NRPM it is placed. By having the statement in section 6.5.4 it leans > towards the first approach, trying to define how an ISP/LIR should > service it's customers. > > Policies should not be written to dictate how an ISP/LIR should > conduct > it's business, but rather how the Internet community should use > resources in a responsible manner. I agree that the proposed > wording in > 6.5.4.1 should be removed. I agree that the proposed wording in > section > 6.5.4.2 should be removed. The problem is, in the absence of a clear > initial and subsequent allocation requirement, ARIN would be left with > nothing to prevent irresponsible practices. > > This is a very subtle difference but seems to be where many proposals > run into issues. As a result, these statements should remain as > guidelines, until the community is comfortable with the development of > the surrounding IPv6 policies. > > My two cents, > Dan > > > ________________________________ > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of > cja at daydream.com > Sent: Thursday, February 15, 2007 5:34 PM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: Removal of Ipv6 Operational > Informationfrom NRPM > > > Hi everyone, > > I would like to have some discussion here about this. For the time > being I have withdrawn this proposal. The reason is that it seems > that > the information that it strikes is information that the ARIN staff > uses > to help guide LIRs to assign reasonable blocks to their customers. > When > an LIR assigns /40s to each of its customers just because, ARIN can > point to the guidelines as to what more reasonable assignments > are. It > is pretty much a given that this information needs to exist somewhere > but it's not quite policy. I'd like your thoughts about this. > > One idea is to have a document that's like the NRPM but contains > operational guidelines for LIRs. Maybe like an NPOG (Number Policy > Operational Guidelines). > > Thanks! > ----Cathy > > > On 2/10/07, Member Services wrote: > > ARIN received the following policy proposal. In accordance with > the ARIN > Internet Resource Policy Evaluation Process, the proposal is > being > posted to the ARIN Public Policy Mailing List (PPML) and being > placed on > ARIN's website. > > The AC will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is > presented; > > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, > > 3. Not accept the proposal as a formal policy proposal. > > The AC will review this proposal at their next meeting. If the > AC > accepts the proposal, then it will be posted as a formal policy > proposal > to PPML and it will be presented at a Public Policy Meeting. If > the AC > does not accept the proposal, then the AC will explain that > decision; > and at that time the author may elect to use the petition > process to > advance their proposal. If the author elects not to petition or > the > petition fails, then the proposal will be closed. > > The ARIN Internet Resource Policy Evaluation Process can be > found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Removal of Ipv6 Operational Information > from NRPM > > Authors: > Lea Roberts > Cathy Aronson > > Proposal Version: Version 0 > > Submission Date: 8 February 2007 > > Proposal type: Modify > > Policy term: Permanent > > Policy statement: > > The following parts of Section 6.5.4.1 should be removed from > the > Number Resource Policy Manual (NRPM). > > NRPM Section 6.5.4.1 states: > > The following guidelines may be useful (but they are only > guidelines): > > * /64 when it is known that one and only one subnet is needed > > * /56 for small sites, those expected to need only a few subnets > over the next 5 years. > > * /48 for larger sites > > Rationale: > > Discussions in recent public policy meetings, as well as in > Advisory > Council meetings, have led to the consensus that operational > information, such as these IPv6 guidelines, should be removed > from the > NRPM. This section is a clear example of text not directly > related to > ARIN policy and so it is proposed that it should be removed. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From hannigan at world.std.com Fri Feb 16 02:12:22 2007 From: hannigan at world.std.com (Martin Hannigan) Date: Fri, 16 Feb 2007 02:12:22 -0500 (EST) Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational In-Reply-To: <85F8E6FA-90D4-4805-BDC9-43E454571E48@delong.com> from "Owen DeLong" at Feb 15, 2007 08:54:54 PM Message-ID: <200702160712.l1G7CMnq028913@world.std.com> > > I think that the root problem is that the RIR and ASO have policy as > their > only tool. The ASO doesn't make policy, we follow guidelines to ratify it according to the MoU signed between ICANN and the RIR's and the ICANN By Laws. > What I believe is needed is an additional tool. If we add a > "recommendation" > tool, then, we have the NRPM for Policy, and the "recommendation > repository" > for recommendations. > > Policy should not dictate how an ISP/LIR operates it's business. > However, > Best common practices and other recommendations could be collected > in such a "recommendations repository" as a community resource without > carrying the force or appearance of policy, thus removing the confusion. > > So, perhaps what is needed is a (rather large) policy proposal that > does the following: > > 1. Create the "recommendations repository" (please, come up with > a better name for it). BCP? RFC? NANOG? -M< From BillD at cait.wustl.edu Fri Feb 16 07:43:11 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 16 Feb 2007 06:43:11 -0600 Subject: [ppml] Policy Proposal: Removal of Ipv6 OperationalInformationfrom NRPM References: <45CDCCF4.6040008@arin.net> <2271C950731A734680BA3E2978816F1808B69116@NJCHLEXCMB01.cable.comcast.com> Message-ID: Well, it is not quite true that the RIR cannot control the assignment practices of a provider. Irresponsible...against the dictates of the RIR...assignment earns the provider a harder time receiving subsequent allocations, right? Still, mostly I agree with what Dan has to say here. Guidance, with rational should be one source of information...you SHOULD not allocated beyond the needs e.g. /56 for.../48 for etc...because... Operational direction, should be another...e.g. this IS the way we do things....e.g. Templates, authentication, etc. Best Practice, perhaps from third parties on aggregation or multihoming practice. All this could be collected and referenced(linked) where needed from within the NRPM. -----Original Message----- From: ppml-bounces at arin.net on behalf of Alexander, Daniel Sent: Thu 2/15/2007 9:33 PM To: cja at daydream.com; ppml at arin.net Subject: Re: [ppml] Policy Proposal: Removal of Ipv6 OperationalInformationfrom NRPM This discussion seems to play along the same lines as the policy proposal to remove the multiple /48 requirement. Both of these skirt around the extent of an RIR's control. One thought is "These statements should be removed." This is because ARIN should not be mandating what an ISP/LIR can allocate to it's users. Even if it wanted to, it has little ability to enforce such a statement, so why try and take this stance. Once an ISP/LIR obtains an allocation, they can allocate in whatever way they feel is necessary. ARIN's main recourse to enforce responsible use is the initial and subsequent allocation requirements. Trying to make these kinds of demands gives ARIN an intrusive image it can't control. The other thought is "These statements should remain." This is because ARIN needs some mechanism to provide direction, in response to organizations seeking guidance, on how to allocate responsibly, and what is expected of them. It is not an issue that the information is in there, but where in the NRPM it is placed. By having the statement in section 6.5.4 it leans towards the first approach, trying to define how an ISP/LIR should service it's customers. Policies should not be written to dictate how an ISP/LIR should conduct it's business, but rather how the Internet community should use resources in a responsible manner. I agree that the proposed wording in 6.5.4.1 should be removed. I agree that the proposed wording in section 6.5.4.2 should be removed. The problem is, in the absence of a clear initial and subsequent allocation requirement, ARIN would be left with nothing to prevent irresponsible practices. This is a very subtle difference but seems to be where many proposals run into issues. As a result, these statements should remain as guidelines, until the community is comfortable with the development of the surrounding IPv6 policies. My two cents, Dan ________________________________ From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of cja at daydream.com Sent: Thursday, February 15, 2007 5:34 PM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM Hi everyone, I would like to have some discussion here about this. For the time being I have withdrawn this proposal. The reason is that it seems that the information that it strikes is information that the ARIN staff uses to help guide LIRs to assign reasonable blocks to their customers. When an LIR assigns /40s to each of its customers just because, ARIN can point to the guidelines as to what more reasonable assignments are. It is pretty much a given that this information needs to exist somewhere but it's not quite policy. I'd like your thoughts about this. One idea is to have a document that's like the NRPM but contains operational guidelines for LIRs. Maybe like an NPOG (Number Policy Operational Guidelines). Thanks! ----Cathy On 2/10/07, Member Services wrote: ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Removal of Ipv6 Operational Information from NRPM Authors: Lea Roberts Cathy Aronson Proposal Version: Version 0 Submission Date: 8 February 2007 Proposal type: Modify Policy term: Permanent Policy statement: The following parts of Section 6.5.4.1 should be removed from the Number Resource Policy Manual (NRPM). NRPM Section 6.5.4.1 states: The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites Rationale: Discussions in recent public policy meetings, as well as in Advisory Council meetings, have led to the consensus that operational information, such as these IPv6 guidelines, should be removed from the NRPM. This section is a clear example of text not directly related to ARIN policy and so it is proposed that it should be removed. Timetable for implementation: Immediate _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml We -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at sprunk.org Fri Feb 16 12:39:23 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 16 Feb 2007 11:39:23 -0600 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM References: <45CDCCF4.6040008@arin.net> Message-ID: <005e01c751f3$4e1fd400$423816ac@atlanta.polycom.com> Thus spake cja at daydream.com > I would like to have some discussion here about this. For the time being > I > have withdrawn this proposal. The reason is that it seems that the > information that it strikes is information that the ARIN staff uses to > help > guide LIRs to assign reasonable blocks to their customers. When an LIR > assigns /40s to each of its customers just because, ARIN can point to > the guidelines as to what more reasonable assignments are. The original intent, IIRC, was to persuade LIRs from assigning _too small_ of a block to customers. In the case of assigning a larger-than-recommended size, the policy already explicitly states that the LIR should send the request to ARIN for guidance. So far, according to Leslie, they have received none, but if they did they would rubber-stamp the request for lack of policy declaring what "justification" means. > It is pretty much a given that this information needs to exist somewhere > but it's not quite policy. I'd like your thoughts about this. True. That text was copied verbatim from an RFC, and was an attempt to give the guidelines some teeth. I think we've failed on execution there, but the idea is sound. There _should_ be some policy on this, and one day we'll get around to writing it once we have a clue what it need to look like. 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 plzak at arin.net Fri Feb 16 16:45:54 2007 From: plzak at arin.net (Ray Plzak) Date: Fri, 16 Feb 2007 16:45:54 -0500 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM In-Reply-To: <85F8E6FA-90D4-4805-BDC9-43E454571E48@delong.com> References: <45CDCCF4.6040008@arin.net> <2271C950731A734680BA3E2978816F1808B69116@NJCHLEXCMB01.cable.comcast.com>, <85F8E6FA-90D4-4805-BDC9-43E454571E48@delong.com> Message-ID: Hi Owen, ARIN does have a suggestion program which allows for submittal of recomendations without using the polichy process inappropriately. Ray ________________________________________ From: ppml-bounces at arin.net [ppml-bounces at arin.net] On Behalf Of Owen DeLong [owen at delong.com] Sent: Thursday, February 15, 2007 11:54 PM To: Alexander, Daniel Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM I think that the root problem is that the RIR and ASO have policy as their only tool. What I believe is needed is an additional tool. If we add a "recommendation" tool, then, we have the NRPM for Policy, and the "recommendation repository" for recommendations. Policy should not dictate how an ISP/LIR operates it's business. However, Best common practices and other recommendations could be collected in such a "recommendations repository" as a community resource without carrying the force or appearance of policy, thus removing the confusion. So, perhaps what is needed is a (rather large) policy proposal that does the following: 1. Create the "recommendations repository" (please, come up with a better name for it). 2. Remove all such recommendations from the NRPM. 3. Add a section to the NRPM stating that non-binding recommendations are retained in the repository and that the NRPM is strictly for binding policies regarding resource allocations. 4. Define a procedure for the updating of the "recommendations repository", probably much like the IRPEP, or, extend the IRPEP to allow it to encompass the creation/modification of such recommendations. 5. Whatever other steps I missed in this process. Owen On Feb 15, 2007, at 7:33 PM, Alexander, Daniel wrote: > > This discussion seems to play along the same lines as the policy > proposal to remove the multiple /48 requirement. Both of these skirt > around the extent of an RIR's control. > > One thought is "These statements should be removed." This is because > ARIN should not be mandating what an ISP/LIR can allocate to it's > users. > Even if it wanted to, it has little ability to enforce such a > statement, > so why try and take this stance. Once an ISP/LIR obtains an > allocation, > they can allocate in whatever way they feel is necessary. ARIN's main > recourse to enforce responsible use is the initial and subsequent > allocation requirements. Trying to make these kinds of demands gives > ARIN an intrusive image it can't control. > > The other thought is "These statements should remain." This is because > ARIN needs some mechanism to provide direction, in response to > organizations seeking guidance, on how to allocate responsibly, and > what > is expected of them. > > It is not an issue that the information is in there, but where in the > NRPM it is placed. By having the statement in section 6.5.4 it leans > towards the first approach, trying to define how an ISP/LIR should > service it's customers. > > Policies should not be written to dictate how an ISP/LIR should > conduct > it's business, but rather how the Internet community should use > resources in a responsible manner. I agree that the proposed > wording in > 6.5.4.1 should be removed. I agree that the proposed wording in > section > 6.5.4.2 should be removed. The problem is, in the absence of a clear > initial and subsequent allocation requirement, ARIN would be left with > nothing to prevent irresponsible practices. > > This is a very subtle difference but seems to be where many proposals > run into issues. As a result, these statements should remain as > guidelines, until the community is comfortable with the development of > the surrounding IPv6 policies. > > My two cents, > Dan > > > ________________________________ > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of > cja at daydream.com > Sent: Thursday, February 15, 2007 5:34 PM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: Removal of Ipv6 Operational > Informationfrom NRPM > > > Hi everyone, > > I would like to have some discussion here about this. For the time > being I have withdrawn this proposal. The reason is that it seems > that > the information that it strikes is information that the ARIN staff > uses > to help guide LIRs to assign reasonable blocks to their customers. > When > an LIR assigns /40s to each of its customers just because, ARIN can > point to the guidelines as to what more reasonable assignments > are. It > is pretty much a given that this information needs to exist somewhere > but it's not quite policy. I'd like your thoughts about this. > > One idea is to have a document that's like the NRPM but contains > operational guidelines for LIRs. Maybe like an NPOG (Number Policy > Operational Guidelines). > > Thanks! > ----Cathy > > > On 2/10/07, Member Services wrote: > > ARIN received the following policy proposal. In accordance with > the ARIN > Internet Resource Policy Evaluation Process, the proposal is > being > posted to the ARIN Public Policy Mailing List (PPML) and being > placed on > ARIN's website. > > The AC will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is > presented; > > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, > > 3. Not accept the proposal as a formal policy proposal. > > The AC will review this proposal at their next meeting. If the > AC > accepts the proposal, then it will be posted as a formal policy > proposal > to PPML and it will be presented at a Public Policy Meeting. If > the AC > does not accept the proposal, then the AC will explain that > decision; > and at that time the author may elect to use the petition > process to > advance their proposal. If the author elects not to petition or > the > petition fails, then the proposal will be closed. > > The ARIN Internet Resource Policy Evaluation Process can be > found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Removal of Ipv6 Operational Information > from NRPM > > Authors: > Lea Roberts > Cathy Aronson > > Proposal Version: Version 0 > > Submission Date: 8 February 2007 > > Proposal type: Modify > > Policy term: Permanent > > Policy statement: > > The following parts of Section 6.5.4.1 should be removed from > the > Number Resource Policy Manual (NRPM). > > NRPM Section 6.5.4.1 states: > > The following guidelines may be useful (but they are only > guidelines): > > * /64 when it is known that one and only one subnet is needed > > * /56 for small sites, those expected to need only a few subnets > over the next 5 years. > > * /48 for larger sites > > Rationale: > > Discussions in recent public policy meetings, as well as in > Advisory > Council meetings, have led to the consensus that operational > information, such as these IPv6 guidelines, should be removed > from the > NRPM. This section is a clear example of text not directly > related to > ARIN policy and so it is proposed that it should be removed. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From info at arin.net Fri Feb 16 17:06:07 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 17:06:07 -0500 Subject: [ppml] Policy Proposal: Creation of Policy for Subsequent End-User IP Requests/Assignments Message-ID: <45D62ACF.3030902@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Creation of Policy for Subsequent End-User IP Requests/Assignments Author: Alex Rubenstein Proposal Version: 1 Submission Date: 15 February 2007 Proposal type: New Policy term: Permanent Policy statement: 4.3.6, Additional Assignments "In order to justify an additional assignment, end-users must have efficiently utilized at least 80% of all previous assignments, and must provide ARIN with utilization details. The prefix size for an additional assignment is determined by applying policies 4.3.2, and 4.3.3." Rationale: There are no published criteria for additional assignment requests from end-user networks. NRPM 4.3 seems to only cover initial assignments. NRPM 4.3.3 states, in part, "Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection." Unfortunately, the above text does not specify any metrics for ARIN staff to apply when determining if an additional assignment is justified. Though most end-users only get one assignment, some end-users request a 2nd or 3rd or Nth assignment. Currently, the ARIN staff applies what they perceive to be "efficient utilization" criteria; for instance, the end-user must have utilized at least 80% of last assignment and must provide ARIN with utilization details. Timetable for implementation: Immediate From info at arin.net Fri Feb 16 17:21:32 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 17:21:32 -0500 Subject: [ppml] Policy Proposal: eGLOP multicast address assignments Message-ID: <45D62E6C.1060506@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: eGLOP multicast address assignments Author: Marshall Eubanks David Meyer Proposal Version: 1 Submission Date: 15 February 2007 Proposal type: new Policy term: permanent Policy statement: RFC 2770 [now replaced by RFC 3180 / BCP 53] set up an automatic "GLOP" multicast address assignment in 233/8 based on Autonomous System Numbers (ASNs). The mechanism that was set up in RFC 3180 for extending GLOP assignments, known as eGLOP, envisioned the assignment of multicast addresses by RIRs from the portion of the 233/8 space corresponding to the RFC 1930 private address space. This mechanism has never been used, but its use has now imperative due to both an increased interest in multicast address assignments to support IPTV and the adopted proposals to assign 4-octet ASNs, which do not have GLOP assignments. This proposal is for the assignment of Multicast addresses by the ARIN RIR using the criteria set up in RFC 3180; equivalent proposals are being sent to the other RIRs for their consideration. Rationale: RFC 2770 [now replaced by RFC 3180 / BCP 53] set up an automatic "GLOP" multicast address assignment in 233/8 based on Autonomous System Numbers (ASNs). The mechanism that was set up in RFC 3180 for extending GLOP assignments, known as eGLOP, envisioned the assignment of multicast addresses by RIRs from the portion of the 233/8 space corresponding to the RFC 1930 private address space. This mechanism has never been used, but its use has now imperative due to both an increased interest in multicast address assignments to support IPTV and the adopted proposals to assign 4-octet ASNs, which do not have GLOP assignments. This proposal is for the assignment of Multicast addresses by the APNIC RIR; equivalent proposals will be sent to the other RIRs for consideration in due course. RFC 2770 and RFC 3180 describe an experimental policy for use of the class D address space by mapping 16 bits of Autonomous System number (AS) into the middle two octets of 233/8 to yield a /24, which is automatically assigned to that ASN. While this technique has been successful, the assignments are inefficient in those cases in which a /24 is too small or the user doesn't have its own AS, and it does not work for 4-octet AS number extension scheme. RFC 3138 expanded on RFC 2770 to allow routing registries to assign multicast addresses from the GLOP space corresponding to the RFC 1930 private AS space; referred to as the EGLOP (Extended GLOP) address space. The failure to instantiate RFC 3138 assignments had lead to a situation where some multicast users feel like they cannot obtain addresses, while others apply directly to IANA, with there being at least 24 approved applications in 2006. The current situations in inequitable and inefficient and there is no reason not to apply the mechanism set up in RFC 3138. RFC 3138 allocated 233.252/14 to eGLOP. The RFC further says that: Globally scoped IPv4 multicast addresses in the EGLOP space are assigned by a Regional Registry (RIR). An applicant MUST, as per [IANA], show that the request cannot be satisfied using Administratively Scoped addressing [RFC2365], GLOP addressing [RFC2770], or SSM. The fine-grained assignment policy is left to the assigning RIR. We propose that each RIR be allocated an initial /20 from this address range, and allocate by default /28's to proposers (16 addresses as Multicast address are not subject to CIDR default restrictions), subject to the above criteria, and that the RIR assign more addresses based on demonstrated need. (Note that Multicast addresses are not subject to classless aggregation and address blocks as small as a /32 can be usefully assigned.) The proposed policy should facilitate multicast deployment. The current mechanism for non-GLOP multicast deployment involves requesting an assignment from IANA, which has no ability to evaluate these requests and relies on the IANA Multicast Expert appointed by the IESG (currently David Meyer). This process is inefficient, inequitable (as this policy route is not widely known), encourages the use of "rogue" self- assignments, and discourages application developers and service providers from developing and deploying multicast. The only disadvantage that we can see from the proposed policy is that the RIR's will have to set up and execute mechanisms to implement it. Effect on APNIC: We feel that adoption of this proposal will help to make multicast deployment more widespread, and should be of benefit to APNIC members adopting Multicast for video distribution on the Internet. References ---------- [IANA] http://www.iana.org/assignments/multicast-addresses [RFC1930] Hawkinson, J., and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998. [RFC2770] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770, February 2000. [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001. [RFC3180] Meyer, D., "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001. Timetable for implementation: Immediately From info at arin.net Fri Feb 16 17:48:22 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 17:48:22 -0500 Subject: [ppml] Policy Proposal 2007-1: Reinstatement of PGP Authentication Method Message-ID: <45D634B6.8090600@arin.net> On 15 February 2007 the ARIN Advisory Council (AC) concluded its review of 'Reinstatement of PGP Authentication Method' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-1: Reinstatement of PGP Authentication Method. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_1.html All persons in the community are encouraged to discuss Policy Proposal 2007-1 prior to it being presented at the ARIN Public Policy Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-1: Reinstatement of PGP Authentication Method Authors: Paul Vixie, Mark Kosters, Chris Morrow, Jared Mauch, Bill Woodcock Proposal type: New Policy term: Permanent Policy statement: ADDITION TO NRPM 12 Authentication Methods 12.1 Mail-From This section intentionally left blank. 12.2 PGP ARIN accepts PGP-signed email as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 12.3 X.509 This section intentionally left blank. UPDATES TO TEMPLATES ARIN shall update templates as necessary to identify and distinguish between mail-from, PGP, and X.509 authentication methods. UPDATES TO DOCUMENTATION ARIN shall update documentation as appropriate to explain the differences between mail-from, PGP, and X.509 authentication methods. KEY USE IN COMMUNICATION: ARIN shall accept PGP-signed communications, validate that a chain of trust not longer than five steps exists between the signing key and the ARIN hostmaster role key, compare the signing key to the identity of the authorized POCs for records referenced in the correspondence, and act appropriately based upon the validity or invalidity of the signature. ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail with their own individual keys. ARIN shall accept PGP-encrypted communications which are encrypted using ARIN's hostmaster public key. ARIN shall not encrypt any outgoing communications except at the prior request of the recipient. Rationale: Globally, PGP is the most commonly used cryptographic authentication method between RIRs and resource recipients who wish to protect their resource registration records against unauthorized modification. The PGP-auth authentication method is supported by RIPE, APNIC, and AfriNIC, LACNIC supports an equivalent mechanism, and PGP was historically supported by the InterNIC prior to ARIN's formation. By contrast, current ARIN resource recipients have only two options: "mail-from," which is trivially spoofed and should not be relied upon to protect important database objects, and X.509, which involves a rigorous and lengthy proof-of-identity process and compels use of a compatible MUA, a combination which has dissuaded essentially all of ARIN's constituents. Additionally, X.509's centralized failure mode is technically and ideologically repugnant to some members of the community, who should not be forced to choose between two evils. There isn't a lot of work to do here, and certainly nothing tricky. PGP is simple code, which was supported by the InterNIC, and which the other RIRs deployed without a second thought or complaint. If RIPE and APNIC have always done this, the InterNIC did it before ARIN was formed, and LACNIC and AfriNIC took the need for cryptographic security for granted as a part of their startup process, we see no reason why ARIN should be the only RIR to not offer this most basic of protections to its members. We need to get PGP support reinstated, so that our records can be protected against hijacking and vandalism, and so we won't look like idiots as the only one of the five regions that can't figure this stuff out. Timetable for implementation: Immediate From info at arin.net Fri Feb 16 17:56:38 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 17:56:38 -0500 Subject: [ppml] Policy Proposal 2007-2: Documentation of the Mail-From Authentication Method Message-ID: <45D636A6.2050502@arin.net> On 15 February 2007 the ARIN Advisory Council (AC) concluded its review of 'Documentation of the Mail-From Authentication Method' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-2: Documentation of the Mail-From Authentication Method. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_2.html All persons in the community are encouraged to discuss Policy Proposal 2007-2 prior to it being presented at the ARIN Public Policy Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## 2007-2: Documentation of the Mail-From Authentication Method Authors: Paul Vixie, Mark Kosters, Chris Morrow, Jared Mauch, Bill Woodcock Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.1 Mail-From This section intentionally left blank. ADDITION TO THE NRPM 12.1 Mail-From Mail-From is the default authentication method by which registration records are protected from vandalism. If a registrant fails to designate a more secure method, any subsequent email which bears the sender address of an authorized Point of Contact may be deemed authentic with regard to the registrant's records. Since it is trivial to forge a sender address, Mail-From should not be regarded as secure. Use of Mail-From authentication is not recommended to any registrant who has the means to implement either of the more secure cryptographic authentication methods. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the mail-from authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Fri Feb 16 17:56:49 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 17:56:49 -0500 Subject: [ppml] Policy Proposal 2007-3: Documentation of the X.509 Authentication Method Message-ID: <45D636B1.8090207@arin.net> On 15 February 2007 the ARIN Advisory Council (AC) concluded its review of 'Documentation of the X.509 Authentication Method' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-3: Documentation of the X.509 Authentication Method. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_3.html All persons in the community are encouraged to discuss Policy Proposal 2007-3 prior to it being presented at the ARIN Public Policy Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-3: Documentation of the X.509 Authentication Method Authors: Paul Vixie, Mark Kosters, Chris Morrow, Jared Mauch, Bill Woodcock Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 12.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Fri Feb 16 18:06:12 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 18:06:12 -0500 Subject: [ppml] Policy Proposal 2007-4: Changes to IPv6 policy - removal of "interim" consideration Message-ID: <45D638E4.5080405@arin.net> On 15 February 2007 the ARIN Advisory Council (AC) concluded its review of 'Changes to IPv6 policy - removal of "interim" consideration' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-4: Changes to IPv6 policy - removal of "interim" consideration. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_4.html All persons in the community are encouraged to discuss Policy Proposal 2007-4 prior to it being presented at the ARIN Public Policy Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-4: Changes to IPv6 policy - removal of "interim" consideration Author: Jordi Palet Martinez Proposal type: delete Policy term: permanent Policy statement: Delete following text at section 6.1.1. of NRPM: "This policy is considered to be an interim policy. It will be reviewed in the future, subject to greater experience in the administration of IPv6." Rationale: The actual text suggest that it is an interim policy, however it is not longer the case. It is clear that any policy is always subjected to changes, however other policies don't have such text. It may be even considered as a negative "message" for IPv6 deployment, especially because the possible "reading" as "not enough experience and this is going to be changed, better wait", which is not a real situation. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Fri Feb 16 18:06:20 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 18:06:20 -0500 Subject: [ppml] Policy Proposal 2007-5: Changes to IPv6 policy - removal of "multiple /48" justification Message-ID: <45D638EC.2060308@arin.net> On 15 February 2007 the ARIN Advisory Council (AC) concluded its review of 'Changes to IPv6 policy - removal of "multiple /48" justification' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-5: Changes to IPv6 policy - removal of "multiple /48" justification. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_5.html All persons in the community are encouraged to discuss Policy Proposal 2007-4 prior to it being presented at the ARIN Public Policy Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-5: Changes to IPv6 policy - removal of "multiple /48" justification Author: Jordi Palet Martinez Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.4.2. of NRPM. Rationale: The current text requires the LIR to justify to the RIR/NIR when assigning multiple /48s to a single end site. It seems that the reason for this requirement is the lack of experience, which seems unreasonable after a few years this policy has been implemented, even if may not have been specific cases which used this policy section. It seems useless, now that there is already deployment experience, to require a justification from the LIR to ARIN for assigning multiple /48s (or a shorter prefix, such as for example a /47). It is up to the LIR to require the justification to its own customers and decide according to it. The LIR will be already responsible to justify to ARIN the usage of any allocated block(s) when requesting for more, and this will already implicate an implicit justification of this kind of assignments. With this policy change, both ARIN and LIR staff will save resources in a justification, which seems unnecessary and should be completely on the hands of the LIR itself. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Fri Feb 16 18:16:01 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 18:16:01 -0500 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text Message-ID: <45D63B31.3010100@arin.net> Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria has been revised. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2006_7.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text Author: Jordi Palet Martinez Proposal Version: 2 Submission Date: 16 February 2007 Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM Policy term: permanent Policy statement: New organizations need a policy that allows them to apply for IPv6 address space. To provide this we need to insert a new additional line item to 6.5.1.1. The new line item would be line 'e' as follows: e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable Rationale: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. -Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. -An ISP or LIR may decide to assign a different prefix size than /48. For example, a cellular operator may use /64. -ASN is not required because as long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. - Organization in this is defined as a Corporation, ISP, LLC et al. In SUMMARY if this policy is implimented the change to the NRPM would read as follows: 6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPV6 address space, an organization must : a be a LIR; b. not be an end site; c. plan to provide IPV6 connectivity to which it will assign IPV6 address space, by advertising that connectivity through its single aggregated address allocation; 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. e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Timetable for implementation: Immediate From owen at delong.com Fri Feb 16 19:07:51 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 16 Feb 2007 16:07:51 -0800 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text In-Reply-To: <45D63B31.3010100@arin.net> References: <45D63B31.3010100@arin.net> Message-ID: I support this policy. I would like to have seen this incorporated into the original IPv6 PI assignment policy, but, it was not politically feasible at the time. Owen > > Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - > revised text > > Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM > Policy statement: > > New organizations need a policy that allows them to apply for IPv6 > address space. To provide this we need to insert a new additional line > item to 6.5.1.1. The new line item would be line 'e' as follows: > > e. OR be an organization new to providing internet services, and can > justify intent to announce the requested IPv6 address space within one > year, through records such as contracts, inventory and/or other > applicable Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From martin.hannigan at batelnet.bs Sun Feb 18 01:46:39 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sun, 18 Feb 2007 01:46:39 -0500 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text Message-ID: <45d7f64f.251.7330.17816@batelnet.bs> > e. OR be an organization new to providing internet > services, and can justify intent to announce the requested > IPV6 address space within one year, through records such > as contracts, inventory and/or other applicable > documentation. What kind of Internet services? -M< From martin.hannigan at batelnet.bs Tue Feb 20 13:17:19 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Tue, 20 Feb 2007 13:17:19 -0500 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text Message-ID: <45db3b2f.340.293e.5150@batelnet.bs> > >> e. OR be an organization new to providing internet > >> services, and can justify intent to announce the > requested >> IPV6 address space within one year, through > records such >> as contracts, inventory and/or other > applicable >> documentation. > > > > > > What kind of Internet services? > > Is there a problem with a broad scope here? Yes. The rationale and the change do not compliment each other. The language of the proposal was also difficult to comprehend. I rewrote it to try and give a clearer view of what *I think* it was stating: e. OR, be an organization new to providing IPV6 internet services, and able to demonstrate intent to advertise the allocated IPV6 space within one year by showing contracts, inventory, or other documentation. -M< From jordi.palet at consulintel.es Tue Feb 20 14:10:10 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 20 Feb 2007 20:10:10 +0100 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text In-Reply-To: <45d7f64f.251.7330.17816@batelnet.bs> Message-ID: Hi Martin, The idea is to be applicable to any kind of Internet Services, as usual for the rest of the policies. I think is very difficult to define that, and even we don't know what "new services" could be available. Furthermore, I don't see a reason to create any restrictions and make it different from other policies. Regards, Jordi > De: Martin Hannigan > Responder a: > Fecha: Sun, 18 Feb 2007 01:46:39 -0500 > Para: > Asunto: Re: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation > criteria - revised text > > >> e. OR be an organization new to providing internet >> services, and can justify intent to announce the requested >> IPV6 address space within one year, through records such >> as contracts, inventory and/or other applicable >> documentation. > > > What kind of Internet services? > > > -M< > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Tue Feb 20 14:28:28 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 20 Feb 2007 20:28:28 +0100 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text In-Reply-To: <45db3b2f.340.293e.5150@batelnet.bs> Message-ID: Hi Martin, I'm not sure, but your proposed text seems to limit the usage of this part of the policy to organizations that ONLY provide IPv6 Internet services, and may not be the case. Basically my intend with this proposal is to support those organizations that aren't "knoww ISPs" (as required by section 6.5.1.1.d). This can fall into two categories (but may be there are others that I don't see right now): 1) An organization which want to provide IPv4 and IPv6 services. 2) An organization which only want to provide IPv6 services. In both cases, seems to me unnecessary to ask for a slow start with *only* IPv4 to be "known" or have a plan for 200/48 (there may be cases which a smaller number of customers and there is no need to force that organization to use a single upstream and get allocated the address space from that upstream, being forced to stay with that upstream on order to avoid renumbering of its network and customer ones). So may be to make sure an alternative option is: e. OR, be an organization new to providing internet services, and able to demonstrate intent to advertise the allocated IPv6 space within one year by showing contracts, inventory, or other documentation. Will that work for you ? What other people think ? Regards, Jordi > De: Martin Hannigan > Responder a: > Fecha: Tue, 20 Feb 2007 13:17:19 -0500 > Para: "Robert E. Seastrom" , Martin Hannigan > > CC: > Asunto: Re: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation > criteria - revised text > > > >>>> e. OR be an organization new to providing internet >>>> services, and can justify intent to announce the >> requested >> IPV6 address space within one year, through >> records such >> as contracts, inventory and/or other >> applicable >> documentation. >>> >>> >>> What kind of Internet services? >> >> Is there a problem with a broad scope here? > > > Yes. The rationale and the change do not compliment > each other. > > The language of the proposal was also difficult to > comprehend. I rewrote it to try and give a clearer > view of what *I think* it was stating: > > e. OR, be an organization new to providing IPV6 internet > services, and able to demonstrate intent to advertise the > allocated IPV6 space within one year by showing contracts, > inventory, or other documentation. > > > -M< > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From william at elan.net Tue Feb 20 15:10:15 2007 From: william at elan.net (william(at)elan.net) Date: Tue, 20 Feb 2007 12:10:15 -0800 (PST) Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text In-Reply-To: <45db3b2f.340.293e.5150@batelnet.bs> References: <45db3b2f.340.293e.5150@batelnet.bs> Message-ID: On Tue, 20 Feb 2007, Martin Hannigan wrote: > The language of the proposal was also difficult to > comprehend. I rewrote it to try and give a clearer > view of what *I think* it was stating: > > e. OR, be an organization new to providing IPV6 internet > services, and able to demonstrate intent to advertise the > allocated IPV6 space within one year by showing contracts, > inventory, or other documentation. "intent to advertise the allocated IPV6 space" ??? Do you even realize what IPv6 is most popular today? No, its not for providing traditional internet services by ISPs which would advertise the space in BGP (btw "advertise" by itself is not complete - you must specify where to advertise to/at rather then imply). The companies that really use IPv6 (and not just play with it for research) do it when they have great many devices that they want to network using TCP/IP and they don't want to use private 10/8 ip space for that. An example given by Randy Bush some time ago was management subnet for cable modem at one large US ISP; another example I have receive from someone else is railroad putting up sensors every few miles. Such use of IPv6 does not require advertising ip space in BGP but we do want these companies using IPv6 as it both provides momentum for others and its less painful for network engineers when they don't have to deal with 10/8 local nets that are mostly separate byt sometimes have to be talk to each other (worst is when two or more companies that use 10/8 merge; but it need not be full merger - just some sort of partnership for services that requires their internet networks to talk to each other is a big issue and may lead to ugly double-NAT setup). P.S. Sorry about being grumpy about what is probably just a simple wording error not done on purpose... And no, I have not kept up with ppml lately due to volume of emails from other activities. -- William Leibzon Elan Networks william at elan.net From stephen at sprunk.org Tue Feb 20 16:52:22 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 20 Feb 2007 15:52:22 -0600 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text References: Message-ID: <010501c7553c$6f53a560$3f3816ac@atlanta.polycom.com> Thus spake "JORDI PALET MARTINEZ" > Basically my intend with this proposal is to support those organizations > that aren't "knoww ISPs" (as required by section 6.5.1.1.d). This can fall > into two categories (but may be there are others that I don't see right > now): > 1) An organization which want to provide IPv4 and IPv6 services. > > 2) An organization which only want to provide IPv6 services. > > In both cases, seems to me unnecessary to ask for a slow start with *only* > IPv4 to be "known" or have a plan for 200/48 (there may be cases which a > smaller number of customers and there is no need to force that > organization > to use a single upstream and get allocated the address space from that > upstream, being forced to stay with that upstream on order to avoid > renumbering of its network and customer ones). It's hardly "slow start" when we're giving every LIR a /32 to start with. That's a lot of addresses. I also don't think that mere intent (even if documented) is sufficient grounds to give an org a globally-routable prefix. If you wish to debate the 200 customer requirement, I'm sure many folks would be open to lowering it, but I cannot in any way support a policy change that allows anyone to get a /32 just because they buy a couple routers and sign up one or two customers. To do so completely undermines the entire the allocation policy; we might as well stop asking for justification entirely and just hand out /32s to everyone who fills out the paperwork. I also question the commercial viability of an ISP that does not offer IPv4 services and plans to subsist for 5+ years on less than 200 customers who are so small they do not qualify for PI assignments. Asking the ISP to make do with PA space (for the year or two it takes to deplete their VC money) is not unreasonable. And, if they do somehow survive, they will qualify as "known" and be able to get an LIR allocation anyways. Again, as with the last time you brought this up, I want to see an actual example (not a hypothetical) that there does exist a company which meets your specifications and has been denied an allocation. Until then, I will remain convinced you are deliberately fabricating a case to demonstrate a perceived loophole in ARIN policy and do not have a bona fide concern. S PS. I also wonder why someone in Spain cares so much about ARIN policies. You're not even proposing the same change here that you proposed in RIPE, for that matter, even though the existing policy for both is identical. 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 jordi.palet at consulintel.es Tue Feb 20 18:41:21 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Feb 2007 00:41:21 +0100 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text In-Reply-To: <010501c7553c$6f53a560$3f3816ac@atlanta.polycom.com> Message-ID: Hi Stephen, See below, in-line. Regards, Jordi > De: Stephen Sprunk > Responder a: > Fecha: Tue, 20 Feb 2007 15:52:22 -0600 > Para: > CC: ARIN PPML > Asunto: Re: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation > criteria - revised text > > Thus spake "JORDI PALET MARTINEZ" >> Basically my intend with this proposal is to support those organizations >> that aren't "knoww ISPs" (as required by section 6.5.1.1.d). This can fall >> into two categories (but may be there are others that I don't see right >> now): >> 1) An organization which want to provide IPv4 and IPv6 services. >> >> 2) An organization which only want to provide IPv6 services. >> >> In both cases, seems to me unnecessary to ask for a slow start with *only* >> IPv4 to be "known" or have a plan for 200/48 (there may be cases which a >> smaller number of customers and there is no need to force that >> organization >> to use a single upstream and get allocated the address space from that >> upstream, being forced to stay with that upstream on order to avoid >> renumbering of its network and customer ones). > > It's hardly "slow start" when we're giving every LIR a /32 to start with. > That's a lot of addresses. May be I've not used the "correct" terminology. My "slow-start" is referring to a few customers (instead of a plan for 200, which can be perfectly exceeded at the end), not the concept of a reduced block. The size of the block is not "relevant" to my policy proposal modification. If we want to enter into that discussion, I think it will be applicable to all the allocations, and then we need to agree in the "typical" filtering rule, etc. I think is a much more complicated topic, also because the increase in the number of routing tables that it can create later on. I think /32 is still reasonable, and what it seems a "waste" now, is not, and instead, smaller blocks and the cost in terms of routing entries is a very bad thing (at least with current routing technologies). > > I also don't think that mere intent (even if documented) is sufficient > grounds to give an org a globally-routable prefix. If you wish to debate > the 200 customer requirement, I'm sure many folks would be open to lowering > it, but I cannot in any way support a policy change that allows anyone to > get a /32 just because they buy a couple routers and sign up one or two > customers. To do so completely undermines the entire the allocation policy; > we might as well stop asking for justification entirely and just hand out > /32s to everyone who fills out the paperwork. I think we need to be fair in what we do with IPv4 and IPv6. If you compare the minimum IPv4 allocation, vs. the IPv6 one in % of the total number of addresses available, may get surprised and the conclusion is that we may need then to change this for IPv4 :-( > > I also question the commercial viability of an ISP that does not offer IPv4 > services and plans to subsist for 5+ years on less than 200 customers who > are so small they do not qualify for PI assignments. Asking the ISP to make > do with PA space (for the year or two it takes to deplete their VC money) is > not unreasonable. And, if they do somehow survive, they will qualify as > "known" and be able to get an LIR allocation anyways. I've some examples of IPv4 ISPs which have just a couple of "big" customers, and for more than 5 years. It works. They could qualify for PI, but we are talking about ISPs, not enterprises. I think the PI policy is targeted to non-ISP cases. > > Again, as with the last time you brought this up, I want to see an actual > example (not a hypothetical) that there does exist a company which meets > your specifications and has been denied an allocation. Until then, I will > remain convinced you are deliberately fabricating a case to demonstrate a > perceived loophole in ARIN policy and do not have a bona fide concern. I don't recall the exact name of at least a couple of people that during the last meeting said "this is my case", but hopefully they are in the list and can speak up. I'm convinced this is valid situation and even more, convinced that the actual policy could be against anti-trust laws, because there is not a valid technical justification for the "200" limitation. I've checked that this is the case in Spain with local lawyers, yes another region, but this kind of laws are typically very similar around the world. > > S > > PS. I also wonder why someone in Spain cares so much about ARIN policies. > You're not even proposing the same change here that you proposed in RIPE, > for that matter, even though the existing policy for both is identical. I do care about policy everywhere. AND this/a similar (differences are due to the discussions in each region, but originally all were almost the same) policy has been submitted in all the regions, including RIPE NCC (http://www.ripe.net/ripe/policies/proposals/2006-02.html). In AfriNIC and LACNIC this specific change is not required because they already changed it LONG time ago, there has not been a significant increase in the number of allocations, which demonstrates that people will not ask for it if not really needed, but some people may be stuck and is not fair. > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Tue Feb 20 19:00:01 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Feb 2007 01:00:01 +0100 Subject: [ppml] FW: NDN: Re: Policy Proposal 2006-7: Changes to IPv6 initial allocation criter In-Reply-To: Message-ID: I guess everybody mailing to ppml is getting this bounce ... I guess somebody from ARIN can unsubscribe this account ? Regards, Jordi Return-path: <> Received: from mx02.kaiapoi.school.nz ([219.88.66.242]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002397868.msg for ; Wed, 21 Feb 2007 00:43:15 +0100 Message-id: Date: Wed, 21 Feb 2007 12:43:46 +1300 Subject: NDN: Re: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criter X-Mailer: FirstClass 8.3 (build 8.272) X-FC-Icon-ID: 2031 X-FC-SERVER-TZ: 83889456 X-FC-MachineGenerated: true To: jordi.palet at consulintel.es From: Gateway MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MDRcpt-To: jordi.palet at consulintel.es X-Rcpt-To: jordi.palet at consulintel.es X-MDRemoteIP: 219.88.66.242 X-Return-Path: X-MDaemon-Deliver-To: jordi.palet at consulintel.es Reply-To: "" X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Wed, 21 Feb 2007 00:43:16 +0100 X-MDAV-Processed: consulintel.es, Wed, 21 Feb 2007 00:43:16 +0100 Sorry. Your message could not be delivered to: caiafotis,Kaiapoi High School (The name was not found at the remote site. Check that the name has been entered correctly.) ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owen at delong.com Tue Feb 20 19:04:09 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Feb 2007 16:04:09 -0800 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text In-Reply-To: <010501c7553c$6f53a560$3f3816ac@atlanta.polycom.com> References: <010501c7553c$6f53a560$3f3816ac@atlanta.polycom.com> Message-ID: <040D2760-A90D-4443-BFDA-057CE276B53C@delong.com> On Feb 20, 2007, at 1:52 PM, Stephen Sprunk wrote: > Thus spake "JORDI PALET MARTINEZ" >> Basically my intend with this proposal is to support those >> organizations >> that aren't "knoww ISPs" (as required by section 6.5.1.1.d). This >> can fall >> into two categories (but may be there are others that I don't see >> right >> now): >> 1) An organization which want to provide IPv4 and IPv6 services. >> >> 2) An organization which only want to provide IPv6 services. >> >> In both cases, seems to me unnecessary to ask for a slow start >> with *only* >> IPv4 to be "known" or have a plan for 200/48 (there may be cases >> which a >> smaller number of customers and there is no need to force that >> organization >> to use a single upstream and get allocated the address space from >> that >> upstream, being forced to stay with that upstream on order to avoid >> renumbering of its network and customer ones). > > It's hardly "slow start" when we're giving every LIR a /32 to start > with. > That's a lot of addresses. > > I also don't think that mere intent (even if documented) is sufficient > grounds to give an org a globally-routable prefix. If you wish to > debate > the 200 customer requirement, I'm sure many folks would be open to > lowering > it, but I cannot in any way support a policy change that allows > anyone to > get a /32 just because they buy a couple routers and sign up one or > two > customers. To do so completely undermines the entire the > allocation policy; > we might as well stop asking for justification entirely and just > hand out > /32s to everyone who fills out the paperwork. > This is another case of trying to have our cake and eat it too. ARIN doesn't control or have anything to do with routability or global routability of prefixes. ARIN only provides uniqueness and registration. So, giving someone a globally unique prefix does not necessarily mean the same thing as a globally routable prefix. Routability is determined on a case-by-case basis by each AS to which the prefix is advertised or attempted to be advertised. It's not ARIN's business or responsibility to get involved in routing decisions, and, the more these types of discussions continue, the more I become convinced that we really need to stop tying address policy decisions to the current set of routing assumptions. Jordi pointed out a number of scenarios in which globally unique addresses are very desirable, yet, will not be globally routed. There's no reason we should avoid doing this in IPv6 where numbers are not scarce. In IPv4, we had a situation where there simplly weren't enough numbers to address the publicly connected needs of the internet in the long run, so, there had to be a priority give to making those unique. As near as I can tell, the ONLY problem IPv6 still solves out of the entire list of problems it was originally intended to solve IS the not enough numbers problem. As such, it does not make sense to me to act as if that problem is not solved in IPv6. > I also question the commercial viability of an ISP that does not > offer IPv4 > services and plans to subsist for 5+ years on less than 200 > customers who > are so small they do not qualify for PI assignments. Asking the > ISP to make > do with PA space (for the year or two it takes to deplete their VC > money) is > not unreasonable. And, if they do somehow survive, they will > qualify as > "known" and be able to get an LIR allocation anyways. > Again, I don't see how that is relevant to ARIN policy. If the ISP is not commercially viable, then, they will stop renewing their ARIN resources and the addresses can be reclaimed (or, they will be absorbed by the acquiring entity). Either way, I don't see how ARIN should be passing judgment on peoples business plans. Owen From bicknell at ufp.org Tue Feb 20 19:26:06 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 20 Feb 2007 19:26:06 -0500 Subject: [ppml] Policy Proposal 2007-1: Reinstatement of PGP Authentication Method In-Reply-To: <45D634B6.8090600@arin.net> References: <45D634B6.8090600@arin.net> Message-ID: <20070221002605.GA90490@ussenterprise.ufp.org> As one of the AC shepards I'd like to solicit some feedback on this proposal. During our review several members of ARIN staff and the AC raised concerns about the exact phrasing of this proposal. As a community many have said we don't want to tell ARIN staff how to operate ARIN through policy, and this proposal has to walk that line. I believe it would be valuable to the authors if some community members could provide their comments on how to best word this policy such that it accomplishes the goal of making PGP authentication available while at the same time allowing ARIN staff to have as much lattitude as possible in the implementation details. Note, while the discussion is with this policy, as it implements something new, it goes hand in hand with 2007-2 and 2007-3, which seek to update the documentation for Mail From and X.509 to be complementary. As always, we also need more comments on if you are for or against this policy. In a message written on Fri, Feb 16, 2007 at 05:48:22PM -0500, Member Services wrote: > On 15 February 2007 the ARIN Advisory Council (AC) concluded its review > of 'Reinstatement of PGP Authentication Method' and accepted it as a > formal policy proposal for discussion by the community. > > The proposal is designated Policy Proposal 2007-1: Reinstatement of PGP > Authentication Method. The proposal text is below and can be found at: > http://www.arin.net/policy/proposals/2007_1.html > > All persons in the community are encouraged to discuss Policy Proposal > 2007-1 prior to it being presented at the ARIN Public Policy Meeting in > San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the > Public Policy Mailing List and at the Public Policy Meeting will be used > to determine the community consensus regarding this policy proposal. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > ARIN's Policy Proposal Archive can be found at: > http://www.arin.net/policy/proposals/proposal_archive.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 2007-1: Reinstatement of PGP Authentication Method > > Authors: > Paul Vixie, > Mark Kosters, > Chris Morrow, > Jared Mauch, > Bill Woodcock > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > ADDITION TO NRPM > > 12 Authentication Methods > > 12.1 Mail-From > This section intentionally left blank. > > 12.2 PGP > ARIN accepts PGP-signed email as authentic communication from authorized > Points of Contact. POCs may denote their records "crypt-auth," > subsequent to which unsigned communications shall not be deemed > authentic with regard to those records. > > 12.3 X.509 > This section intentionally left blank. > > UPDATES TO TEMPLATES > > ARIN shall update templates as necessary to identify and distinguish > between mail-from, PGP, and X.509 authentication methods. > > UPDATES TO DOCUMENTATION > > ARIN shall update documentation as appropriate to explain the > differences between mail-from, PGP, and X.509 authentication methods. > > KEY USE IN COMMUNICATION: > > ARIN shall accept PGP-signed communications, validate that a chain of > trust not longer than five steps exists between the signing key and the > ARIN hostmaster role key, compare the signing key to the identity of the > authorized POCs for records referenced in the correspondence, and act > appropriately based upon the validity or invalidity of the signature. > > ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster > role key, and staff members may optionally also sign mail with their own > individual keys. > > ARIN shall accept PGP-encrypted communications which are encrypted using > ARIN's hostmaster public key. > > ARIN shall not encrypt any outgoing communications except at the prior > request of the recipient. > > Rationale: > > Globally, PGP is the most commonly used cryptographic authentication > method between RIRs and resource recipients who wish to protect their > resource registration records against unauthorized modification. The > PGP-auth authentication method is supported by RIPE, APNIC, and AfriNIC, > LACNIC supports an equivalent mechanism, and PGP was historically > supported by the InterNIC prior to ARIN's formation. By contrast, > current ARIN resource recipients have only two options: "mail-from," > which is trivially spoofed and should not be relied upon to protect > important database objects, and X.509, which involves a rigorous and > lengthy proof-of-identity process and compels use of a compatible MUA, a > combination which has dissuaded essentially all of ARIN's constituents. > Additionally, X.509's centralized failure mode is technically and > ideologically repugnant to some members of the community, who should not > be forced to choose between two evils. > > There isn't a lot of work to do here, and certainly nothing tricky. PGP > is simple code, which was supported by the InterNIC, and which the other > RIRs deployed without a second thought or complaint. If RIPE and APNIC > have always done this, the InterNIC did it before ARIN was formed, and > LACNIC and AfriNIC took the need for cryptographic security for granted > as a part of their startup process, we see no reason why ARIN should be > the only RIR to not offer this most basic of protections to its members. > > We need to get PGP support reinstated, so that our records can be > protected against hijacking and vandalism, and so we won't look like > idiots as the only one of the five regions that can't figure this stuff out. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- 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 pekkas at netcore.fi Wed Feb 21 05:24:46 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Feb 2007 12:24:46 +0200 (EET) Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text In-Reply-To: <45d7f64f.251.7330.17816@batelnet.bs> References: <45d7f64f.251.7330.17816@batelnet.bs> Message-ID: On Sun, 18 Feb 2007, Martin Hannigan wrote: >> e. OR be an organization new to providing internet >> services, and can justify intent to announce the requested >> IPV6 address space within one year, through records such >> as contracts, inventory and/or other applicable >> documentation. > > What kind of Internet services? Martin raises a good point. If I set up an IPv6 web server for virtual hosting, do I qualify under e)? That's under "internet services" and one could say "justify intent to announce ..." (does ARIN have a way to validate that justification?). I think the policy meant to refer to providing IPv6 _connectivity_ services to other organizations..(?) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From michael.dillon at bt.com Wed Feb 21 05:33:35 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 21 Feb 2007 10:33:35 -0000 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C1011D3682@i2km07-ukbr.domain1.systemhost.net> > e. OR, be an organization new to providing internet services, > and able to > demonstrate intent to advertise the allocated IPv6 space > within one year by > showing contracts, inventory, or other documentation. Be careful with the words "advertise" and "announce". You don't say who, where, or how. Nobody ever needs to announce their address space on the public Internet. They merely need to announce it to another AS. The logic of your change is faulty. You are trying to stick an OR in a list of ANDs. Better to change d to read: d. and meet one or more of the following criteria: 1) be an existing known ISP in the ARIN region 2) have a plan for making at least 200 /48 assignments to other organizations within five years 3) be an organization new to providing Internet services who can document the intent to provide IPv6 services within one year Of course, maybe the details are not quite what you had in mind. Also, it would be best to reword b, and c to explicitly include the word "and". Or maybe you want "and" at the end of an item? In any case, matching the structure of the lists to the ands and ors seems like a good idea to me. --Michael Dillon P.S. Maybe the staff can fix the darn website so that a person can copy and paste content from the NPRM pages. Try it. Left-click somewhere in the text and drag the mouse right to select a couple of words. It doesn't work in IE. Now try the same on a random website. It works on 99.44% of sites but not on ARIN. From jordi.palet at consulintel.es Wed Feb 21 05:48:01 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Feb 2007 11:48:01 +0100 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text In-Reply-To: Message-ID: Hi Pekka, No, I think this is not the case. If you read the complete policy, it is clear that point c still apply: c. plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through its single aggregated address allocation; and So only organizations which plan to provide connectivity to other organizations can get a prefix assigned. Regards, Jordi > De: Pekka Savola > Responder a: > Fecha: Wed, 21 Feb 2007 12:24:46 +0200 (EET) > Para: Martin Hannigan > CC: > Asunto: Re: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation > criteria - revised text > > On Sun, 18 Feb 2007, Martin Hannigan wrote: >>> e. OR be an organization new to providing internet >>> services, and can justify intent to announce the requested >>> IPV6 address space within one year, through records such >>> as contracts, inventory and/or other applicable >>> documentation. >> >> What kind of Internet services? > > Martin raises a good point. > > If I set up an IPv6 web server for virtual hosting, do I qualify under > e)? > > That's under "internet services" and one could say "justify intent to > announce ..." (does ARIN have a way to validate that justification?). > > I think the policy meant to refer to providing IPv6 _connectivity_ > services to other organizations..(?) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Wed Feb 21 05:56:46 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Feb 2007 11:56:46 +0100 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text In-Reply-To: <2DA00C5A2146FB41ABDB3E9FCEBC74C1011D3682@i2km07-ukbr.domain1.systemhost.net> Message-ID: Hi Michael, This is a good point. I think it should be advertised to the next hop(s) (another AS ?). But this is already said in section c, so no need to be added again ? Also, regarding the OR and ANDs, it is something that may be fixed by the staff or the AC, without the need to submit a new policy proposal ? Regards, Jordi > De: > Responder a: > Fecha: Wed, 21 Feb 2007 10:33:35 -0000 > Para: > Conversaci?n: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial > allocation criteria - revised text > Asunto: Re: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation > criteria - revised text > >> e. OR, be an organization new to providing internet services, >> and able to >> demonstrate intent to advertise the allocated IPv6 space >> within one year by >> showing contracts, inventory, or other documentation. > > Be careful with the words "advertise" and "announce". You don't say who, > where, or how. Nobody ever needs to announce their address space on the > public Internet. They merely need to announce it to another AS. > > The logic of your change is faulty. You are trying to stick an OR in a > list of ANDs. Better to change d to read: > > d. and meet one or more of the following criteria: > > 1) be an existing known ISP in the ARIN region > 2) have a plan for making at least 200 /48 assignments to other > organizations within five years > 3) be an organization new to providing Internet services who can > document the intent to provide IPv6 services within one year > > Of course, maybe the details are not quite what you had in mind. Also, > it would be best to reword b, and c to explicitly include the word > "and". Or maybe you want "and" at the end of an item? In any case, > matching the structure of the lists to the ands and ors seems like a > good idea to me. > > --Michael Dillon > > P.S. Maybe the staff can fix the darn website so that a person can copy > and paste content from the NPRM pages. Try it. Left-click somewhere in > the text and drag the mouse right to select a couple of words. It > doesn't work in IE. Now try the same on a random website. It works on > 99.44% of sites but not on ARIN. > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From stephen at sprunk.org Wed Feb 21 08:59:33 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 21 Feb 2007 07:59:33 -0600 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text References: Message-ID: <006901c755c1$85d81b10$6601a8c0@atlanta.polycom.com> Thus spake "JORDI PALET MARTINEZ" > No, I think this is not the case. > > If you read the complete policy, it is clear that point c still apply: > > c. plan to provide IPv6 connectivity to organizations to which it will > assign IPv6 address space, by advertising that connectivity through its > single aggregated address allocation; and > > So only organizations which plan to provide connectivity to other > organizations can get a prefix assigned. You mean allocated. If an org does not provide connectivity, they're classified as an "end site", not an LIR, and the allocation policy explicitly does not apply to them. However, ARIN has a direct assignment policy to cover those folks (unlike other RIRs, AFAIK). Aside: It's not entirely clear to me if a provider not connected to the public Internet can become an LIR; does private "connectivity" and "advertising" count? 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 bt.com Wed Feb 21 09:52:49 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 21 Feb 2007 14:52:49 -0000 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initialallocation criteria - revised text Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C1011D3DAD@i2km07-ukbr.domain1.systemhost.net> > Aside: It's not entirely clear to me if a provider not > connected to the > public Internet can become an LIR; does private "connectivity" and > "advertising" count? It counts. RFC 2050 still applies even to IPv6 addressing. I think our main problem with IPv6 policy is the ISP-centric wording. For instance, a railway sensor network that spans North America seems to fit into the category "end-site" which is a totally irrational way to describe such a network. One way to address this issue is to restructure the policy and make some implicit things explicit. For instance: ===== Secition A) ARIN provides allocations of IPv6 address space to organizations who operate continually growing networks which connect many other organizations together. The classic examples of this are the ISP (Internet Service Provider), the VAN (Value-Added Network) and the Industry Extranet (automotive, financial services). These organizations become ARIN LIRs(Local Internet Registries) and are expected to provide assignments of IPv6 address space to organizations who connect to their networks. Section B) ARIN also provides assignments of IPv6 address space to organizations who are building an IPv6 network that remains largely under their control with limited interconnectivity with other networks. This ranges from enterprises to railway consortia to cellphone operators. The key distinguishing characteristic of these organizations is that their networks are not continually growing at such a scale that they have to plan for additional allocations of IPv6 addresses at regular intervals. In other words, they are not network service providers whose prime business is network connectivity services. ===== Given something like this in the policy, then it becomes simpler to address the area under contention. Organizations cannot receive IPv6 addresses under both section A and section B. Section A organizations must provide sufficient documentation to show that they are providing IPv6 network services or will do so within the first year after receiving an allocation. Section A organizations must sign an LIR agreement with ARIN. Section A organizations must maintain an active abuse desk contact with ARIN. Section A organizations must ... You can see what I am getting at. We've been hacking away at minor adjustments to this wording for ages with no resolution. People can't agree because they don't share the same understanding of the existing wording. This lack of shared understanding then extends to the minor changes as well. The solution is to rework a larger section of policy (or multiple sections of policy) to get some much clearer prose in place which is unambiguous. In the process, there are some things that are not clearly spelled out in the policy and they could be. I know it is hard for the ISP-oriented folks to see this so I hope some of the corporate members will step up and contribute here. ARIN policy does not have to be so mystifying. --Michael Dillon From terry.l.davis at boeing.com Wed Feb 21 15:01:48 2007 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Wed, 21 Feb 2007 12:01:48 -0800 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocation criteria - revised text In-Reply-To: <2DA00C5A2146FB41ABDB3E9FCEBC74C1011D3DAD@i2km07-ukbr.domain1.systemhost.net> References: <2DA00C5A2146FB41ABDB3E9FCEBC74C1011D3DAD@i2km07-ukbr.domain1.systemhost.net> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A01BD3094@XCH-NW-8V1.nw.nos.boeing.com> Michael Excellent commentary! For the readers to consider in thinking about your comments: The aviation industry will be developing at least three independent IP networks serving each commercial aircraft flying the world. These networks will span the entire globe! (We have several airlines that have aircraft that literally complete a circle of the globe every few days.) The air traffic control network will be closed as it is today. But the addressing still ideally should come from a single block of addresses (sub-addressed between aircraft and ground system). And these addresses will need to be pooled, distributed, and managed under the rules of the International Civil Aviation Organization. In ICAO's case, they will need the allocation years ahead of the first actual use as they will have to make their allocations from that space to the airlines and governments around the world. The airline networks, for their business communications with their fleets, will also need to almost certainly use a global network design. As will the onboard networks dedicated to serving the passengers for both Internet and live video content to the seat back. I think you will see the same requirements from the maritime and several other industries. Industry and business needs the some type of consideration here. Take care Terry PS: Especially "critical infrastructure"! Next time you are at home and the snow is really deep outside and the wind blowing or it is really hot and the air conditioner is going full tilt, ask yourself if you would like for your power company to be planning switching ISP's that day and re-addressing all their SCADA systems across three or four states? And can you imagine when would be a good time for an airline (even a small one) to switch ISP's without potentially disrupting your travel someway? Or consider any other critical infrastructure that you have to deal with daily and remember critical infrastructure includes small businesses; hospitals, clinics, banks, local fuel distributor, refineries, gas company, etc. When would be a convenient time for them to change ISP's and switch addresses so no one was impacted? > -----Original Message----- > From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] > Sent: Wednesday, February 21, 2007 6:53 AM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2006-7: Changes to > IPv6initialallocation criteria - revised text > > > Aside: It's not entirely clear to me if a provider not > > connected to the > > public Internet can become an LIR; does private "connectivity" and > > "advertising" count? > > It counts. RFC 2050 still applies even to IPv6 addressing. > > I think our main problem with IPv6 policy is the ISP-centric wording. > For instance, a railway sensor network that spans North America seems to > fit into the category "end-site" which is a totally irrational way to > describe such a network. > > One way to address this issue is to restructure the policy and make some > implicit things explicit. For instance: > ===== > Secition A) ARIN provides allocations of IPv6 address space to > organizations who operate continually growing networks which connect > many other organizations together. The classic examples of this are the > ISP (Internet Service Provider), the VAN (Value-Added Network) and the > Industry Extranet (automotive, financial services). These organizations > become ARIN LIRs(Local Internet Registries) and are expected to provide > assignments of IPv6 address space to organizations who connect to their > networks. > > Section B) ARIN also provides assignments of IPv6 address space to > organizations who are building an IPv6 network that remains largely > under their control with limited interconnectivity with other networks. > This ranges from enterprises to railway consortia to cellphone > operators. The key distinguishing characteristic of these organizations > is that their networks are not continually growing at such a scale that > they have to plan for additional allocations of IPv6 addresses at > regular intervals. In other words, they are not network service > providers whose prime business is network connectivity services. > ===== > > Given something like this in the policy, then it becomes simpler to > address the area under contention. > > Organizations cannot receive IPv6 addresses under both section A and > section B. > > Section A organizations must provide sufficient documentation to show > that they are providing IPv6 network services or will do so within the > first year after receiving an allocation. > > Section A organizations must sign an LIR agreement with ARIN. > > Section A organizations must maintain an active abuse desk contact with > ARIN. > > Section A organizations must ... > > You can see what I am getting at. We've been hacking away at minor > adjustments to this wording for ages with no resolution. People can't > agree because they don't share the same understanding of the existing > wording. This lack of shared understanding then extends to the minor > changes as well. The solution is to rework a larger section of policy > (or multiple sections of policy) to get some much clearer prose in place > which is unambiguous. In the process, there are some things that are not > clearly spelled out in the policy and they could be. I know it is hard > for the ISP-oriented folks to see this so I hope some of the corporate > members will step up and contribute here. ARIN policy does not have to > be so mystifying. > > --Michael Dillon > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From emmiesan at msn.com Wed Feb 21 15:23:21 2007 From: emmiesan at msn.com (Tanya Hinman) Date: Wed, 21 Feb 2007 15:23:21 -0500 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocation criteria - revised text Message-ID: Terry,It is good to see such enormous progress around the globe in a seemingly peaceful manner. A time when IPv6 will definitely be put to the use it was initially intended for. After years of working with and watching the slow progress of IPv6, my mind is now at ease! Thank you for the information to the world.With Truth and Honour,Tanya Hinman, RNIP Address Engineer919-272-1835807 Quickstone DrFuquay-Varina, NC 27526United States of AmericaMy life in the plane was a place of peace. Let us work to place the peace globally across the Nation and our World.> Date: Wed, 21 Feb 2007 12:01:48 -0800> From: terry.l.davis at boeing.com> To: michael.dillon at bt.com; ppml at arin.net> Subject: Re: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocation criteria - revised text> > Michael> > Excellent commentary!> > For the readers to consider in thinking about your comments:> The aviation industry will be developing at least three independent IP> networks serving each commercial aircraft flying the world. These> networks will span the entire globe! (We have several airlines that> have aircraft that literally complete a circle of the globe every few> days.)> > The air traffic control network will be closed as it is today. But the> addressing still ideally should come from a single block of addresses> (sub-addressed between aircraft and ground system). And these addresses> will need to be pooled, distributed, and managed under the rules of the> International Civil Aviation Organization. In ICAO's case, they will> need the allocation years ahead of the first actual use as they will> have to make their allocations from that space to the airlines and> governments around the world.> > The airline networks, for their business communications with their> fleets, will also need to almost certainly use a global network design.> > As will the onboard networks dedicated to serving the passengers for> both Internet and live video content to the seat back.> > I think you will see the same requirements from the maritime and several> other industries.> > Industry and business needs the some type of consideration here.> > Take care> Terry> > PS: Especially "critical infrastructure"! Next time you are at home and> the snow is really deep outside and the wind blowing or it is really hot> and the air conditioner is going full tilt, ask yourself if you would> like for your power company to be planning switching ISP's that day and> re-addressing all their SCADA systems across three or four states?> > And can you imagine when would be a good time for an airline (even a> small one) to switch ISP's without potentially disrupting your travel> someway? > > Or consider any other critical infrastructure that you have to deal with> daily and remember critical infrastructure includes small businesses;> hospitals, clinics, banks, local fuel distributor, refineries, gas> company, etc. When would be a convenient time for them to change ISP's> and switch addresses so no one was impacted?> > > -----Original Message-----> > From: michael.dillon at bt.com [mailto:michael.dillon at bt.com]> > Sent: Wednesday, February 21, 2007 6:53 AM> > To: ppml at arin.net> > Subject: Re: [ppml] Policy Proposal 2006-7: Changes to> > IPv6initialallocation criteria - revised text> > > > > Aside: It's not entirely clear to me if a provider not> > > connected to the> > > public Internet can become an LIR; does private "connectivity" and> > > "advertising" count?> > > > It counts. RFC 2050 still applies even to IPv6 addressing.> > > > I think our main problem with IPv6 policy is the ISP-centric wording.> > For instance, a railway sensor network that spans North America seems> to> > fit into the category "end-site" which is a totally irrational way to> > describe such a network.> > > > One way to address this issue is to restructure the policy and make> some> > implicit things explicit. For instance:> > =====> > Secition A) ARIN provides allocations of IPv6 address space to> > organizations who operate continually growing networks which connect> > many other organizations together. The classic examples of this are> the> > ISP (Internet Service Provider), the VAN (Value-Added Network) and the> > Industry Extranet (automotive, financial services). These> organizations> > become ARIN LIRs(Local Internet Registries) and are expected to> provide> > assignments of IPv6 address space to organizations who connect to> their> > networks.> > > > Section B) ARIN also provides assignments of IPv6 address space to> > organizations who are building an IPv6 network that remains largely> > under their control with limited interconnectivity with other> networks.> > This ranges from enterprises to railway consortia to cellphone> > operators. The key distinguishing characteristic of these> organizations> > is that their networks are not continually growing at such a scale> that> > they have to plan for additional allocations of IPv6 addresses at> > regular intervals. In other words, they are not network service> > providers whose prime business is network connectivity services.> > =====> > > > Given something like this in the policy, then it becomes simpler to> > address the area under contention.> > > > Organizations cannot receive IPv6 addresses under both section A and> > section B.> > > > Section A organizations must provide sufficient documentation to show> > that they are providing IPv6 network services or will do so within the> > first year after receiving an allocation.> > > > Section A organizations must sign an LIR agreement with ARIN.> > > > Section A organizations must maintain an active abuse desk contact> with> > ARIN.> > > > Section A organizations must ...> > > > You can see what I am getting at. We've been hacking away at minor> > adjustments to this wording for ages with no resolution. People can't> > agree because they don't share the same understanding of the existing> > wording. This lack of shared understanding then extends to the minor> > changes as well. The solution is to rework a larger section of policy> > (or multiple sections of policy) to get some much clearer prose in> place> > which is unambiguous. In the process, there are some things that are> not> > clearly spelled out in the policy and they could be. I know it is hard> > for the ISP-oriented folks to see this so I hope some of the corporate> > members will step up and contribute here. ARIN policy does not have to> > be so mystifying.> > > > --Michael Dillon> > > > > > _______________________________________________> > PPML mailing list> > PPML at arin.net> > http://lists.arin.net/mailman/listinfo/ppml> _______________________________________________> PPML mailing list> PPML at arin.net> http://lists.arin.net/mailman/listinfo/ppml _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Feb 21 17:06:43 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Feb 2007 23:06:43 +0100 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocation criteria - revised text In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A01BD3094@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: Hi Terry, Quick question. Are those addresses being advertised to Internet ? If not, you could use ULA-central ? Regards, Jordi > De: "Davis, Terry L" > Responder a: > Fecha: Wed, 21 Feb 2007 12:01:48 -0800 > Para: , > Conversaci?n: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocation > criteria - revised text > Asunto: Re: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocation > criteria - revised text > > Michael > > Excellent commentary! > > For the readers to consider in thinking about your comments: > The aviation industry will be developing at least three independent IP > networks serving each commercial aircraft flying the world. These > networks will span the entire globe! (We have several airlines that > have aircraft that literally complete a circle of the globe every few > days.) > > The air traffic control network will be closed as it is today. But the > addressing still ideally should come from a single block of addresses > (sub-addressed between aircraft and ground system). And these addresses > will need to be pooled, distributed, and managed under the rules of the > International Civil Aviation Organization. In ICAO's case, they will > need the allocation years ahead of the first actual use as they will > have to make their allocations from that space to the airlines and > governments around the world. > > The airline networks, for their business communications with their > fleets, will also need to almost certainly use a global network design. > > As will the onboard networks dedicated to serving the passengers for > both Internet and live video content to the seat back. > > I think you will see the same requirements from the maritime and several > other industries. > > Industry and business needs the some type of consideration here. > > Take care > Terry > > PS: Especially "critical infrastructure"! Next time you are at home and > the snow is really deep outside and the wind blowing or it is really hot > and the air conditioner is going full tilt, ask yourself if you would > like for your power company to be planning switching ISP's that day and > re-addressing all their SCADA systems across three or four states? > > And can you imagine when would be a good time for an airline (even a > small one) to switch ISP's without potentially disrupting your travel > someway? > > Or consider any other critical infrastructure that you have to deal with > daily and remember critical infrastructure includes small businesses; > hospitals, clinics, banks, local fuel distributor, refineries, gas > company, etc. When would be a convenient time for them to change ISP's > and switch addresses so no one was impacted? > >> -----Original Message----- >> From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] >> Sent: Wednesday, February 21, 2007 6:53 AM >> To: ppml at arin.net >> Subject: Re: [ppml] Policy Proposal 2006-7: Changes to >> IPv6initialallocation criteria - revised text >> >>> Aside: It's not entirely clear to me if a provider not >>> connected to the >>> public Internet can become an LIR; does private "connectivity" and >>> "advertising" count? >> >> It counts. RFC 2050 still applies even to IPv6 addressing. >> >> I think our main problem with IPv6 policy is the ISP-centric wording. >> For instance, a railway sensor network that spans North America seems > to >> fit into the category "end-site" which is a totally irrational way to >> describe such a network. >> >> One way to address this issue is to restructure the policy and make > some >> implicit things explicit. For instance: >> ===== >> Secition A) ARIN provides allocations of IPv6 address space to >> organizations who operate continually growing networks which connect >> many other organizations together. The classic examples of this are > the >> ISP (Internet Service Provider), the VAN (Value-Added Network) and the >> Industry Extranet (automotive, financial services). These > organizations >> become ARIN LIRs(Local Internet Registries) and are expected to > provide >> assignments of IPv6 address space to organizations who connect to > their >> networks. >> >> Section B) ARIN also provides assignments of IPv6 address space to >> organizations who are building an IPv6 network that remains largely >> under their control with limited interconnectivity with other > networks. >> This ranges from enterprises to railway consortia to cellphone >> operators. The key distinguishing characteristic of these > organizations >> is that their networks are not continually growing at such a scale > that >> they have to plan for additional allocations of IPv6 addresses at >> regular intervals. In other words, they are not network service >> providers whose prime business is network connectivity services. >> ===== >> >> Given something like this in the policy, then it becomes simpler to >> address the area under contention. >> >> Organizations cannot receive IPv6 addresses under both section A and >> section B. >> >> Section A organizations must provide sufficient documentation to show >> that they are providing IPv6 network services or will do so within the >> first year after receiving an allocation. >> >> Section A organizations must sign an LIR agreement with ARIN. >> >> Section A organizations must maintain an active abuse desk contact > with >> ARIN. >> >> Section A organizations must ... >> >> You can see what I am getting at. We've been hacking away at minor >> adjustments to this wording for ages with no resolution. People can't >> agree because they don't share the same understanding of the existing >> wording. This lack of shared understanding then extends to the minor >> changes as well. The solution is to rework a larger section of policy >> (or multiple sections of policy) to get some much clearer prose in > place >> which is unambiguous. In the process, there are some things that are > not >> clearly spelled out in the policy and they could be. I know it is hard >> for the ISP-oriented folks to see this so I hope some of the corporate >> members will step up and contribute here. ARIN policy does not have to >> be so mystifying. >> >> --Michael Dillon >> >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From terry.l.davis at boeing.com Wed Feb 21 18:49:33 2007 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Wed, 21 Feb 2007 15:49:33 -0800 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocationcriteria - revised text Message-ID: <0D090F1E0F5536449C7E6527AFFA280A01BD309C@XCH-NW-8V1.nw.nos.boeing.com> Jordi Yes and no. The addresses for air traffic control systems will not be advertised. Most likely the addresses for the airline business and operations onboard systems and the IFE providers will be. There will be three entirely separate networks on an aircraft and due to both international regulations and legal issues they MUST be separate. Take care Terry > -----Original Message----- > From: JORDI PALET MARTINEZ [mailto:jordi.palet at consulintel.es] > Sent: Wednesday, February 21, 2007 2:07 PM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2006-7: Changes to > IPv6initialallocationcriteria - revised text > > Hi Terry, > > Quick question. Are those addresses being advertised to Internet ? If not, > you could use ULA-central ? > > Regards, > Jordi > > > > > > De: "Davis, Terry L" > > Responder a: > > Fecha: Wed, 21 Feb 2007 12:01:48 -0800 > > Para: , > > Conversaci?n: [ppml] Policy Proposal 2006-7: Changes to > IPv6initialallocation > > criteria - revised text > > Asunto: Re: [ppml] Policy Proposal 2006-7: Changes to > IPv6initialallocation > > criteria - revised text > > > > Michael > > > > Excellent commentary! > > > > For the readers to consider in thinking about your comments: > > The aviation industry will be developing at least three independent IP > > networks serving each commercial aircraft flying the world. These > > networks will span the entire globe! (We have several airlines that > > have aircraft that literally complete a circle of the globe every few > > days.) > > > > The air traffic control network will be closed as it is today. But the > > addressing still ideally should come from a single block of addresses > > (sub-addressed between aircraft and ground system). And these addresses > > will need to be pooled, distributed, and managed under the rules of the > > International Civil Aviation Organization. In ICAO's case, they will > > need the allocation years ahead of the first actual use as they will > > have to make their allocations from that space to the airlines and > > governments around the world. > > > > The airline networks, for their business communications with their > > fleets, will also need to almost certainly use a global network design. > > > > As will the onboard networks dedicated to serving the passengers for > > both Internet and live video content to the seat back. > > > > I think you will see the same requirements from the maritime and several > > other industries. > > > > Industry and business needs the some type of consideration here. > > > > Take care > > Terry > > > > PS: Especially "critical infrastructure"! Next time you are at home and > > the snow is really deep outside and the wind blowing or it is really hot > > and the air conditioner is going full tilt, ask yourself if you would > > like for your power company to be planning switching ISP's that day and > > re-addressing all their SCADA systems across three or four states? > > > > And can you imagine when would be a good time for an airline (even a > > small one) to switch ISP's without potentially disrupting your travel > > someway? > > > > Or consider any other critical infrastructure that you have to deal with > > daily and remember critical infrastructure includes small businesses; > > hospitals, clinics, banks, local fuel distributor, refineries, gas > > company, etc. When would be a convenient time for them to change ISP's > > and switch addresses so no one was impacted? > > > >> -----Original Message----- > >> From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] > >> Sent: Wednesday, February 21, 2007 6:53 AM > >> To: ppml at arin.net > >> Subject: Re: [ppml] Policy Proposal 2006-7: Changes to > >> IPv6initialallocation criteria - revised text > >> > >>> Aside: It's not entirely clear to me if a provider not > >>> connected to the > >>> public Internet can become an LIR; does private "connectivity" and > >>> "advertising" count? > >> > >> It counts. RFC 2050 still applies even to IPv6 addressing. > >> > >> I think our main problem with IPv6 policy is the ISP-centric wording. > >> For instance, a railway sensor network that spans North America seems > > to > >> fit into the category "end-site" which is a totally irrational way to > >> describe such a network. > >> > >> One way to address this issue is to restructure the policy and make > > some > >> implicit things explicit. For instance: > >> ===== > >> Secition A) ARIN provides allocations of IPv6 address space to > >> organizations who operate continually growing networks which connect > >> many other organizations together. The classic examples of this are > > the > >> ISP (Internet Service Provider), the VAN (Value-Added Network) and the > >> Industry Extranet (automotive, financial services). These > > organizations > >> become ARIN LIRs(Local Internet Registries) and are expected to > > provide > >> assignments of IPv6 address space to organizations who connect to > > their > >> networks. > >> > >> Section B) ARIN also provides assignments of IPv6 address space to > >> organizations who are building an IPv6 network that remains largely > >> under their control with limited interconnectivity with other > > networks. > >> This ranges from enterprises to railway consortia to cellphone > >> operators. The key distinguishing characteristic of these > > organizations > >> is that their networks are not continually growing at such a scale > > that > >> they have to plan for additional allocations of IPv6 addresses at > >> regular intervals. In other words, they are not network service > >> providers whose prime business is network connectivity services. > >> ===== > >> > >> Given something like this in the policy, then it becomes simpler to > >> address the area under contention. > >> > >> Organizations cannot receive IPv6 addresses under both section A and > >> section B. > >> > >> Section A organizations must provide sufficient documentation to show > >> that they are providing IPv6 network services or will do so within the > >> first year after receiving an allocation. > >> > >> Section A organizations must sign an LIR agreement with ARIN. > >> > >> Section A organizations must maintain an active abuse desk contact > > with > >> ARIN. > >> > >> Section A organizations must ... > >> > >> You can see what I am getting at. We've been hacking away at minor > >> adjustments to this wording for ages with no resolution. People can't > >> agree because they don't share the same understanding of the existing > >> wording. This lack of shared understanding then extends to the minor > >> changes as well. The solution is to rework a larger section of policy > >> (or multiple sections of policy) to get some much clearer prose in > > place > >> which is unambiguous. In the process, there are some things that are > > not > >> clearly spelled out in the policy and they could be. I know it is hard > >> for the ISP-oriented folks to see this so I hope some of the corporate > >> members will step up and contribute here. ARIN policy does not have to > >> be so mystifying. > >> > >> --Michael Dillon > >> > >> > >> _______________________________________________ > >> PPML mailing list > >> PPML at arin.net > >> http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From martin.hannigan at batelnet.bs Thu Feb 22 01:41:53 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 22 Feb 2007 01:41:53 -0500 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text Message-ID: <45dd3b31.6e.4e8e.20021@batelnet.bs> > > I also question the commercial viability of an ISP that > > does not offer IPv4 > > services and plans to subsist for 5+ years on less than > > 200 customers who > > are so small they do not qualify for PI assignments. > > Asking the ISP to make > > do with PA space (for the year or two it takes to > > deplete their VC money) is > > not unreasonable. And, if they do somehow survive, they > > will qualify as > > "known" and be able to get an LIR allocation anyways. > > > Again, I don't see how that is relevant to ARIN policy. > If the ISP is not commercially > viable, then, they will stop renewing their ARIN resources > and the addresses > can be reclaimed (or, they will be absorbed by the > acquiring entity). Either > way, I don't see how ARIN should be passing judgment on > peoples business plans. That year or two is a risk buffer. Weakening or altogether removing start requirements increases the risk to the resources and the organization. -M< From michael.dillon at bt.com Thu Feb 22 05:22:47 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 22 Feb 2007 10:22:47 -0000 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocation criteria - revised text Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C10122D7DE@i2km07-ukbr.domain1.systemhost.net> > Quick question. Are those addresses being advertised to > Internet ? If not, > you could use ULA-central ? There is no such thing. Google shows me that ULA-central is something that was described in an IETF draft which has since expired. Expired draft documents are meaningless as far as ARIN policy is concerned. On the other hand, RFC 2050 is an IETF Best Practice document that is the foundation of the entire RIR system. In section 3 "Assignment Framework" it explicitly states: In order for the Internet to scale using existing technologies, use of regional registry services should be limited to the assignment of IP addresses for organizations meeting one or more of the following conditions: 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. The reference to RFC 1918 is for private networks, i.e. networks that are under one single administrative control and will never interconnect with another network. It is also an IPv4 specific concept so it does not apply to IPv6. --Michael Dillon From info at arin.net Thu Feb 22 10:59:06 2007 From: info at arin.net (Member Services) Date: Thu, 22 Feb 2007 10:59:06 -0500 Subject: [ppml] Policy Proposal: IPv4 countdown policy proposal Message-ID: <45DDBDCA.6060405@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 countdown policy proposal Author: Toshiyuki Hosaka (Japan Network Information Center (JPNIC)) Co-Authors: Takashi Arano (Intec Netcore, Inc.) Kuniaki Kondo (Atelier Mahoroba) Tomohiro Fujisaki (NTT) Akinori Maemura (JPNIC) Kosuke Ito (IRI Ubitech) Shuji Nakamura (IPv6 Promotion Council) Tomoya Yoshida (NTT Communications) Susumu Sato (JPNIC) Akira Nakagawa (KDDI) Proposal Version: 1 Submission Date: 22 February 2007 Proposal type: new Policy term: renewable Policy statement: - Set the date for termination of (IPv4) allocations and the date of announcement Set the date to terminate allocations as a general rule, and announce it a certain period in advance. Define the date of announcement as "A-date" and the date to terminate allocations as "T-date". The two dates will be set as follows: A-date (Date of Announcement): - The day in which the IANA pool becomes less than 30*/8 - RIRs must announce "T-date" on this day, which is defined later (*) There will be no changes in the policy on A-date T-date(Date of Termination): - Exactly two years after A-date - 10*/8 blocks should remain at T-date, and defined as two years after A-date, based on the current pace of allocations - It is however possible to move T-date forward at the point where address consumpution exceeds the projections during the course of two years (*) new allocations/assignments from RIRs should terminate on T-date as a general rule. Allocations or assignments to "critical infrastructure" after T-date should be defined by a separate policy. Rationale: 1. Introduction The exhaustion of IPv4 address is approaching round the corner. Geoff Huston's latest projection at Potaroo (as of January 6, 2007) (http://www.potaroo.net/tools/ipv4/) draws the date of IANA pool exhaustion as 31st May 2011, and that of RIR pool as 14th July 2012. Tony Hain projects similar dates based on a different algorithm of his own. From these data, we may observe that if that the current allocation trend continues, the exhaustion of IPv4 address space is expected to take place as early as within the next five years. ICANN/IANA and RIRs must co-ordinate with stakeholders to achieve smooth termination of IPv4 address space as the Internet bodies responsible for stable management and distribution of IP number resources. This proposal provides some ideas as well as concrete examples of the policy that helps IPv4 allocations come to an end with "the minimum confusion" and in "as fair manner as possible". "Five years at the earliest" is not too far in the future for the exhaustion of IPv4 address space. Assuming the minimum of one year is required for sufficient policy discussions with this proposal as a start, and two years for preparation and transfer by LIRs, we need to start the discussions right at this time. 2. Summary of current problems Despite the fact that several projections are made on IPv4 address to run out as early as within the next few years, no discussions are taking place on any of the RIR's policy fora. (we have submitted the same proposal to APNIC on January 2007) This section lists possible problems if no policies are defined to prepare for the terminal period of allocations. 2-1. LIR LIRs currently do not consider IPv4 address exhaustion as an imminent issue in the first place. It is possible that they will finally realize the situation only when impacts of the exhaustion becomes visible as a practical matter, and lead to confusions such as re-addressing their network or making subsequent requests at the last minute in within a limited time frame. There could also be cases where allocations blocks cannot be allocated to some of the LIRs even though requests are submitted on the same day. Moreover, although it would be necessary for LIRs to announce to their customers that IPv4 address space will not be available for assignments eventually, it is difficult to plan this timing without clear policy for the last phase of allocations. As new IPv4 address allocations space will no longer be available, LIRs have no choice but to build networks based on IPv6. However, there are risks of trouble if preparations are made from that point in time, as it will lead to premature actions even if some time can be bought by re-addressing and subsequent allocations. Lastly, using up all available IPv4 address space will disable assignments to services inevitable for co-existence of IPv4 and IPv6 networks, such as the translator service between the two networks, which it may create situation where transfer to IPv6 network will not even be possible. 2-2. RIR/NIR It is likely that smooth allocations by RIRs/NIRs will be hindered by rush of inquiries during the terminal phase of allocations. 2-3. End users End users generally receive address assignments from ISPs accompanied with Internet connection service. If an ISP no longer has IPv4 address space available, nor unable to provide IPv6 service, end users will not be able to receive services from that ISP. Moreover, if the terminal date of allocations remains ambiguous, it may leave end users behind to prepare for IPv6 ready network. 3. Benefits There will be the following benefits by implementing the policy for IPv4 address exhaustion as proposed on this paper. 3-1. LIR LIRs will be able to consciously plan their addressing within their networks if the final date of allocations is clearly demonstrated. Keeping a certain amount of unallocated address blocks enables allocations/assignments for "critical infrastructure" after the termination of regular allocations, which will be explained later section in more details. 3-2. RIR/NIR Announcing the date of terminating allocations in advance and ensuring that all allocations before this date will be made according to the policy at the time enables RIRs/NIRs to make the last allocation without confusions and avoids causing feelings of unfairness among LIRs and end users. In addition, consistent policy applied to all RIRs removes bias towards certain region as well as inter-regional unfairness. The period which IPv6 support is completed becomes clear, therefore, RIRs/NIRs can prepare for this. 3-3. End user As this proposal enables LIRs to prepare for the terminal period of allocations in advance, it reduces the risk of delays/ suspensions of assignments from LIRs to enduers, and end users will be able to continuously receive services from LIRs. As in the case of LIRs, end users will be able to prepare for IPv6 support by the date of allocation termination is clarified. In addition, IPv6 connectivity as well as IPv4 address required during the allocation termination period will be smoothly secured by LIRs preparing for such period. As listed above, there will be important, notable benefits for stakeholders as a result of this policy. It is therefore necessary to take the following actions to achieve a smooth transfer to IPv6 and prevent causing instability in the Internet as well as; - start discussions on allocation scheme during the exhaustion period, - indicate a roadmap to exhaustion after raising awareness on the issue, and - allow enough time for LIRs to plan timing of addressing of their networks, submit allocation requests, and consider how to switch to IPv6. 4. Proposal principles As the first step to discuss IPv4 exhaustion planning, we would like to have an agreement(consensus) on the following four principles. -------------------------------------------------------------------- (1) Global synchronization: All five RIRs will proceed at the same time for measures on IPv4 address exhaustion. (2) Some Blocks to be left: Keep a few /8 stocks instead of distributing all. (3) Keeping current practices until the last moment : Maintain the current policy until the last allocation. (4) Separate discussions on "Recycle" issue : Recovery of unused address space should be discussed separately. -------------------------------------------------------------------- (1) Global synchronization: All RIRs must proceed at the same time to take measures for IPv4 address exhaustion. This is important not only for ensuring fairness for LIRs across the regions, but alsot to prevent confusions such as attempts to receive allocations from an RIR outside their region. The five RIRs should facilitate bottom-up discussions, which should be well coordinated under the leaderships of ICANN ASO and NRO. (2) Some blocks to be left: It is not practical to consider that IPv4 address blocks can be allocated to the last piece. It is expected to cause confusions if one party can receive an allocation while the other has to give up, just with a touch of a difference. The best solution to avoid such confusion is to set in advance, a date in which one is able to receive an allocation if requests are submitted before this timeline. Furthermore, there are few cases where allocations or assignments of IPv4 address space become absolutely necessary in the future. For example, requirements to start a translator service between IPv4 and IPv6 networks should be supported, and there may be some requirements in the future that are beyond our imagination at this current moment. As such, a date to stop allocations under the current policy should be set/defined so that certain number of IPv4 address blocks will be kept as stocks instead of allocating all blocks without remains. (3) Maintaining current practices until the last moment : Allocations should be made based on the current policy until the time to terminate allocations. As the IPv4 Internet has now developed into a social infrastructure supporting large number of businesses, making large changes in the current policy towards conservation within the next one or two years will lead to large-scale confusions, and difficult in the reality. (4) Separate discussion from "Recycle" issue Recovering unused allocated/assigned address blocks is an important measure, and in fact, it has already be discussed and implemented in each RIR regions. This issue, however should be considered separately from this proposal as recovery of a few /8 blocks extends the lifetime of IPv4 for less than one year while efforts for the recovery is expected to require substantial time. 5. Rationale for "A-date" & "T-date" A-date is set in order to: - Allow some grace period and period for networks to be IPv6 ready until the termination of allocations. - Prevent unfairness among LIRs by clarifying the date, such as not being able to receive allocations by a small difference in timing. The rationale for setting A-date as "when IANA pool becomes less than 30*/8" is as follows: The rate of allocations from IANA to RIRs after 2000 is as follows. 2000 : 4*/8 2001 : 6*/8 2002 : 4*/8 2003 : 5*/8 2004 : 9*/8 2005 : 13*/8 2006 : 10*/8 Approximately 10*/8 has been allocated annually after 2003, and the consumption is likely to accelerate with rise of the last minute demands. As it is better to keep minimum stocks of address pool at IANA, 30*/8 is set as the threshold value, and allocations should be terminated two years after it reaches the value, which ensures that IANA/RIRs secure the address space for allocations/assignments to critical infrastructure. 6. Effect on RIR members RIR members are expected to concretely grasp the termination date of allocations and take actions within their organization to prepare for the event. Timetable for implementation: Immediate after all 5 RIRs ratified this policy. From narten at us.ibm.com Thu Feb 22 11:04:48 2007 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 22 Feb 2007 11:04:48 -0500 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Information from NRPM In-Reply-To: References: <45CDCCF4.6040008@arin.net> Message-ID: <200702221604.l1MG4mSc027084@cichlid> Hi Cathy. > I would like to have some discussion here about this. For the time being I > have withdrawn this proposal. The reason is that it seems that the > information that it strikes is information that the ARIN staff uses to help > guide LIRs to assign reasonable blocks to their customers. When an LIR > assigns /40s to each of its customers just because, ARIN can point to the > guidelines as to what more reasonable assignments are. It is pretty much a > given that this information needs to exist somewhere but it's not quite > policy. I'd like your thoughts about this. I concur. Indeed, at the time the wording at issue was formulated (and I was one of the authors of the proposal), I believed that having no wording would result in no guidance being available, and (channeling concerns from some in the IETF community) there was a real concern that the default practice would be give end sites "too small" a block, precisely because that would be the default approach given IPv4 existing practice. > One idea is to have a document that's like the NRPM but contains > operational guidelines for LIRs. Maybe like an NPOG (Number Policy > Operational Guidelines). I think this is really what is needed. Something more detailed, with more background and things to think about, etc. And it is arguably more global than specific to one RIR, since the issues to consider are presumably universal. Where/how should such a document be developed and housed? v6ops (in the IETF) might be one place, even if not ideal. Thomas From marla.azinger at frontiercorp.com Thu Feb 22 11:34:44 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 22 Feb 2007 11:34:44 -0500 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DDA7@nyrofcs2ke2k01.corp.pvt> Thomas- Although we need to consider IETF regulations and guidance, the purpose here is not to write an IETF Golobal document. The purpose of this is to provide quick guidance to the ARIN Community. This project is focusing only on taking "non policy" information out of the NRPM and relocating it in a easy to read and understand document for the ARIN Community. I'm not saying that its not possible a Global IETF document of this nature could have merit or be written, it's just not the intent, and it would also be a challenge to write given this information we are talking about hedges on policy. Cheers Marla Azinger -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Thomas Narten Sent: Thursday, February 22, 2007 8:05 AM To: cja at daydream.com Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM Hi Cathy. > I would like to have some discussion here about this. For the time being I > have withdrawn this proposal. The reason is that it seems that the > information that it strikes is information that the ARIN staff uses to help > guide LIRs to assign reasonable blocks to their customers. When an LIR > assigns /40s to each of its customers just because, ARIN can point to the > guidelines as to what more reasonable assignments are. It is pretty much a > given that this information needs to exist somewhere but it's not quite > policy. I'd like your thoughts about this. I concur. Indeed, at the time the wording at issue was formulated (and I was one of the authors of the proposal), I believed that having no wording would result in no guidance being available, and (channeling concerns from some in the IETF community) there was a real concern that the default practice would be give end sites "too small" a block, precisely because that would be the default approach given IPv4 existing practice. > One idea is to have a document that's like the NRPM but contains > operational guidelines for LIRs. Maybe like an NPOG (Number Policy > Operational Guidelines). I think this is really what is needed. Something more detailed, with more background and things to think about, etc. And it is arguably more global than specific to one RIR, since the issues to consider are presumably universal. Where/how should such a document be developed and housed? v6ops (in the IETF) might be one place, even if not ideal. Thomas _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Thu Feb 22 18:35:00 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Feb 2007 15:35:00 -0800 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text In-Reply-To: <45dd3b31.6e.4e8e.20021@batelnet.bs> References: <45dd3b31.6e.4e8e.20021@batelnet.bs> Message-ID: <36F1BAEF-B539-482F-B4BA-F87FD87526A1@delong.com> On Feb 21, 2007, at 10:41 PM, Martin Hannigan wrote: > > > >>> I also question the commercial viability of an ISP that >>> does not offer IPv4 >>> services and plans to subsist for 5+ years on less than >>> 200 customers who >>> are so small they do not qualify for PI assignments. >>> Asking the ISP to make >>> do with PA space (for the year or two it takes to >>> deplete their VC money) is >>> not unreasonable. And, if they do somehow survive, they >>> will qualify as >>> "known" and be able to get an LIR allocation anyways. >>> >> Again, I don't see how that is relevant to ARIN policy. >> If the ISP is not commercially >> viable, then, they will stop renewing their ARIN resources >> and the addresses >> can be reclaimed (or, they will be absorbed by the >> acquiring entity). Either >> way, I don't see how ARIN should be passing judgment on >> peoples business plans. > > > That year or two is a risk buffer. Weakening or altogether > removing start requirements increases the risk to the > resources and the organization. I don't buy it. First, I don't know what you mean by 'risk to the resources and the organization'. There really aren't any "risks" here. Either the business succeeds in which case the resources remain allocated, or, the business fails in which case the resources can be reclaimed. It's as simple as that. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Thu Feb 22 18:41:07 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Feb 2007 15:41:07 -0800 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DDA7@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A01A3DDA7@nyrofcs2ke2k01.corp.pvt> Message-ID: <1BE0CEBD-96CA-447E-A544-AAE076B9E317@delong.com> On Feb 22, 2007, at 8:34 AM, Azinger, Marla wrote: > Thomas- Although we need to consider IETF regulations and > guidance, the purpose here is not to write an IETF Golobal > document. The purpose of this is to provide quick guidance to the > ARIN Community. > > This project is focusing only on taking "non policy" information > out of the NRPM and relocating it in a easy to read and understand > document for the ARIN Community. > > I'm not saying that its not possible a Global IETF document of this > nature could have merit or be written, it's just not the intent, > and it would also be a challenge to write given this information we > are talking about hedges on policy. Perhaps a hybrid of the two... Perhaps start by creating the ARIN NPOG and pass the idea along to the other RIRs to adopt or not. If there is consensus among the 5 RIRs to create something similar as a global document, that could be done easily enough at that later date. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From info at arin.net Thu Feb 22 20:59:53 2007 From: info at arin.net (Member Services) Date: Thu, 22 Feb 2007 20:59:53 -0500 Subject: [ppml] Policy Proposal: Transfer Policy Clarifications Message-ID: <45DE4A99.7070207@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Transfer Policy Clarifications Author: Paul Andersen Proposal Version: 1.0 Submission Date: February 22, 2007 Proposal type: Modify Policy term: Permanent Policy statement: That Section 8 of the NRPM is replaced as follows: 8.1. Transfers Number resources are non-transferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer. ARIN is tasked with making prudent decisions on whether to approve the transfer of number resources. It should be understood that number resources are not "sold" under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, provided the terms of the Registration Services Agreement continue to be met and the stated purpose for the number resources remains the same. Number resources are administered and assigned according to ARIN's published policies. Number resources are issued, based on justified need, to organizations, not to individuals representing those organizations. Thus, if a company goes out of business, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources if a transfer is not requested and justified. 8.2 Transfer Requirements ARIN will consider requests for the transfer of number resources only upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity's use of the number resource. Examples of assets that justify use of the number resource include, but are not limited to: * Existing customer base * Qualified hardware inventory * Specific software requirements 8.3. Documentation Requirements In evaluating a request for transfer, ARIN may require the requesting organization to provide any of the following documents, as applicable, plus any other documents deemed appropriate: * An authenticated copy of the instrument(s) effecting the transfer of assets, e.g., bill of sale, certificate of merger, contract, deed, or court decree * A detailed inventory of all assets utilized by the requesting party in maintaining and using the number resource * A list of the requesting party's customers using the number resources If further justification is required, the requesting party may be asked to provide any of the following, or other supporting documentation, as applicable: * A general listing of the assets or components acquired * A specific description of acquisitions, including: * Type and quantity of equipment * Customer base * A description of how address space is being utilized * Network engineering plans, including: * Host counts * Subnet masking * Network diagrams * Reassignments to customers Rationale: Staff analysis and community comments have a problem with the inconsistent use of the terms "ASN" and "IP Address" in this section which leads to confusion on which resources can be transferred. The entire section now utilizes the term "number resources" to clarify what would appear to be the original intent. A section regarding the handling of customer networks outside ARIN's geographic region has been removed to reflect the actual current procedure utilized that was developed in conjunction with the ERX transfer project. The last section of old text has been removed as it does not appear to be so much policy as guidance. Timetable for implementation: Immediate From packetgrrl at gmail.com Thu Feb 22 21:03:38 2007 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 22 Feb 2007 19:03:38 -0700 Subject: [ppml] Policy Proposal: Removal of Ipv6 Operational Informationfrom NRPM In-Reply-To: <1BE0CEBD-96CA-447E-A544-AAE076B9E317@delong.com> References: <454810F09B5AA04E9D78D13A5C39028A01A3DDA7@nyrofcs2ke2k01.corp.pvt> <1BE0CEBD-96CA-447E-A544-AAE076B9E317@delong.com> Message-ID: The other point to make here is that although there may be a "global policy" for things like IPv6 or even IPv4 (RFC2050), the operational mechanism and guidelines very significantly from RIR to RIR. How you apply, what mechanism for verifying utilization, even in some cases whether you can assign a certain size block to a customer, vary from RIR to RIR. There are also guidelines like the ones I was proposing we strike that are used by ARIN but not necessarily by any other RIR. Then there are things like actual IP address allocation/assignment policies that vary from region to region. It is not clear to me that we're ever going to have all this stuff globalized. Meanwhile they're not really policy so it would be good to have them all in one place and available for the ARIN community. I am agreeing with you Owen :-) I think we have to start with the ARIN community and then if the idea gets adopted in other regions that's great. ---Cathy On 2/22/07, Owen DeLong wrote: > > > On Feb 22, 2007, at 8:34 AM, Azinger, Marla wrote: > > > Thomas- Although we need to consider IETF regulations and > > guidance, the purpose here is not to write an IETF Golobal > > document. The purpose of this is to provide quick guidance to the > > ARIN Community. > > > > This project is focusing only on taking "non policy" information > > out of the NRPM and relocating it in a easy to read and understand > > document for the ARIN Community. > > > > I'm not saying that its not possible a Global IETF document of this > > nature could have merit or be written, it's just not the intent, > > and it would also be a challenge to write given this information we > > are talking about hedges on policy. > > Perhaps a hybrid of the two... Perhaps start by creating the ARIN > NPOG and pass the > idea along to the other RIRs to adopt or not. If there is consensus > among the 5 RIRs > to create something similar as a global document, that could be done > easily enough > at that later date. > > Owen > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Thu Feb 22 22:38:19 2007 From: info at arin.net (Member Services) Date: Thu, 22 Feb 2007 22:38:19 -0500 Subject: [ppml] Policy Proposal: Modernization of ISP Immediate Need Policy Message-ID: <45DE61AB.4080708@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Modernization of ISP Immediate Need Policy Author: Robert Seastrom Proposal Version: 1.0 Submission Date: 22-Feb-2007 Proposal type: modify Policy term: permanent Policy statement: Modify NRPM 4.2.1.6 to read: If an ISP has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. Current text of 4.2.1.6: If an ISP has an immediate need for address space, i.e., the need exists the day of the request, ARIN may issue a /20 if the organization, such as a new company, shows justification. However, these cases are exceptional. Rationale: ARIN staff and ARIN members have identified a few long-standing problems with the Immediate Need policy. This policy proposal attempts to address the following concerns: * The Immediate Need policy only allows ISPs to qualify for a /20 worth of space, when a larger size block may be necessary to provide proper coverage for the proposed project. An example justifying larger space is an MSOs for which a /20 is insufficient to put an address block larger than a /29 or /30 on each CMTS in a metropolitan area). * Conversely, this policy was written before the current multi-homed policy (which allows allocations of /21s and /22s). The Immediate Need policy should allow assignment of smaller blocks of space if those are justified. * The example used in the Immediate Need policy gives the impression that an immediate need must exist the day of the request. This seems both unfair and unreasonable and should probably be changed to reflect a realistic timeframe. Concerns expressed about the Immediate Need Policy but NOT addressed by this policy proposal (but addressed in a subsequent policy proposal): * The policy as written allows ARIN to issue a /20 to an ISP only. However, section 4.3.4. "Additional Considerations" of the End User Policy in the NRPM states that "End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4].". In order to be consistent, the Immediate Need policy language should be changed to reflect the fact that both ISPs and end-users can qualify under this policy. Timetable for implementation: Immediate From info at arin.net Thu Feb 22 22:38:49 2007 From: info at arin.net (Member Services) Date: Thu, 22 Feb 2007 22:38:49 -0500 Subject: [ppml] Policy Proposal: End Site Immediate Need Policy Message-ID: <45DE61C9.1040507@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: End Site Immediate Need Policy Author: Robert Seastrom Proposal Version: 1.0 Submission Date: 22-Feb-2007 Proposal type: new Policy term: permanent Policy statement: Create new section in NRPM 4.3.6. to mirror the intent of 4.2.1.6, but modified for end sites. If pending proposal "Modernization of ISP Immediate Need Policy" is ratified, this new section will read: 4.3.6 Immediate Need: If an end-user has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. In the absence of ratification of ""Modernization of ISP Immediate Need Policy", this proposal is to add section 4.3.6 with a modification of the current text of 4.2.1.6 to make it apply to end-users: 4.3.6 Immediate Need: If an end-user has an immediate need for address space, i.e., the need exists the day of the request, ARIN may issue a /20 if the organization, such as a new company, shows justification. However, these cases are exceptional. Rationale: ARIN staff has expressed the concern that the current policy is self-contradictory, in one place stating that the Immediate Need Policy applies to ISPs, and in another place stating that end users can qualify under it. The communication received was: * The policy as written allows ARIN to issue a /20 to an ISP only. However, section 4.3.4. "Additional Considerations" of the End User Policy in the NRPM states that "End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4].". In order to be consistent, the Immediate Need policy language should be changed to reflect the fact that both ISPs and end-users can qualify under this policy. Timetable for implementation: Immediate From info at arin.net Thu Feb 22 22:39:30 2007 From: info at arin.net (Member Services) Date: Thu, 22 Feb 2007 22:39:30 -0500 Subject: [ppml] Policy Proposal: Refinement of ISP Initial Allocation Policy Message-ID: <45DE61F2.9060907@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Refinement of ISP Initial Allocation Policy Author: Robert Seastrom Proposal Version: 1.0 Submission Date: 22-Feb-2007 Proposal type: modify Policy term: permanent Policy statement: In NRPM 4.2.4.3 (Initial Allocations to ISPs Policy), strike the following sentence: "When completing Section 7 of the ARIN ISP Network Request Template, please keep this in mind" Rationale: Instructions on filling out templates properly belong in the instructions attached to the template, not as part of a policy statement. This reminder makes reference to an obsolete template and section. ARIN released new templates in August 2006 and changed template names, field numbers, and sections which made both of these references obsolete. Timetable for implementation: Immediate From michael.dillon at bt.com Fri Feb 23 04:36:11 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 23 Feb 2007 09:36:11 -0000 Subject: [ppml] Policy Proposal: Transfer Policy Clarifications Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C10128F98D@i2km07-ukbr.domain1.systemhost.net> > ARIN will consider requests for the transfer of number resources only > upon receipt of evidence that the new entity has acquired the assets > which had, as of the date of the acquisition or proposed > reorganization, > justified the current entity's use of the number resource. Examples of > assets that justify use of the number resource include, but are not > limited to: > > * Existing customer base > * Qualified hardware inventory > * Specific software requirements Very strange list. If the buyer takes over the functioning network, or the components of the functioning network such as "circuit contracts" and PoPs, then it is clear that they justify the addresses. But this is missing from the proposed policy. On the other hand, if they are gutting the acquisition and supply a customer list and an autioneer's list of routers, switches, and servers, this somehow justifies keeping the addresses? Of course the current policy is just as broken, but if you are going to fix this section, why not really fix it. This policy gets too deep into details that don't need to be in policy. The fact is, that the new owner has to justify their use of addresses on the same basis as any new applicant. If policy needs to have any details of what justifies addresses then it should be listed in one place and that should not be in the "transfer" section. Also, policy cannot override the law. If an org changes its name or becomes a wholly owned subsidiary, the transfer should be as simple as changing the org template. If the org is dismantling its network, then that is a situation where policy should call for an audit or refer to the requirements for RECEIVING an allocation. I'm all for fixing the "number resources" confusion but I think this section of policy has stuff which doesn't belong there. --Michael Dillon From info at arin.net Fri Feb 23 14:06:59 2007 From: info at arin.net (Member Services) Date: Fri, 23 Feb 2007 14:06:59 -0500 Subject: [ppml] ARIN XIX Meeting Registration Open Message-ID: <45DF3B53.5010005@arin.net> ARIN invites you to attend the ARIN XIX Public Policy and Members Meeting, to be held 22-25 April 2007 in San Juan, Puerto Rico. Registration for ARIN XIX is now open. Links to meeting and remote participation information, as well as other meeting information is available at http://www.arin.net/ARIN-XIX/. ARIN holds open, biannual Public Policy and Members Meetings, providing an opportunity for the entire Internet community to contribute to Internet number resource policy discussions and development, network with colleagues, and attend workshops and tutorials. Community participation is the basis of the ARIN policy development process and current policy proposals up for discussion at this meeting are available at: http://www.arin.net/policy/proposals/proposal_archive.html ARIN XIX Overview * Sunday, 22 April - ARIN is excited to offer a "Practical Guide to IPv6 " workshop. This workshop will combine elements of the previous "Getting Started with IPv6" workshops and last fall's "Networking with IPv6" workshop. It will focus on providing hands-on experience using IPv6 on your own laptop and information on IPv6 operations over a network. Sunday activities will also include a lunch for first-time ARIN meeting attendees, a tutorial, an Introduction to IRPEP session, the Open Policy Hour, and the 8th Annual Foosball Tournament. * Monday, 23 April - ARIN Public Policy Meeting, Day 1, evening ARIN Social * Tuesday, 24 April - ARIN Public Policy Meeting, Day 2 * Wednesday, 25 April - ARIN Members Meeting (open to all ARIN XIX attendees) Additional agenda details and more information about ARIN XIX will be posted to our website as we get closer to the meeting, so check back often! Regards, Member Services Department American Registry for Internet Numbers (ARIN) From owen at delong.com Sun Feb 25 00:22:51 2007 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Feb 2007 21:22:51 -0800 Subject: [ppml] Policy Proposal: End Site Immediate Need Policy In-Reply-To: <45DE61C9.1040507@arin.net> References: <45DE61C9.1040507@arin.net> Message-ID: I support this policy. It seems a reasonable interpretation of the intent of existing policy. Owen On Feb 22, 2007, at 7:38 PM, Member Services wrote: > ARIN received the following policy proposal. In accordance with the > ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being > placed on > ARIN's website. > > The AC will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is presented; > > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, > > 3. Not accept the proposal as a formal policy proposal. > > The AC will review this proposal at their next meeting. If the AC > accepts the proposal, then it will be posted as a formal policy > proposal > to PPML and it will be presented at a Public Policy Meeting. If the AC > does not accept the proposal, then the AC will explain that decision; > and at that time the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: End Site Immediate Need Policy > > Author: Robert Seastrom > > Proposal Version: 1.0 > > Submission Date: 22-Feb-2007 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Create new section in NRPM 4.3.6. to mirror the intent of 4.2.1.6, but > modified for end sites. If pending proposal "Modernization of ISP > Immediate Need Policy" is ratified, this new section will read: > > 4.3.6 Immediate Need: > > If an end-user has an immediate need for address space, and can > provide > justification to show that the address space will be utilized > within 30 > days of the request, ARIN may issue a block of address space, not > larger > than a /16 nor smaller than ARIN's customary minimum allocation, to > that > organization. These cases are exceptional. > > In the absence of ratification of ""Modernization of ISP Immediate > Need > Policy", this proposal is to add section 4.3.6 with a modification of > the current text of 4.2.1.6 to make it apply to end-users: > > 4.3.6 Immediate Need: > > If an end-user has an immediate need for address space, i.e., the > need > exists the day of the request, ARIN may issue a /20 if the > organization, > such as a new company, shows justification. However, these cases are > exceptional. > > Rationale: > > ARIN staff has expressed the concern that the current policy is > self-contradictory, in one place stating that the Immediate Need > Policy > applies to ISPs, and in another place stating that end users can > qualify > under it. The communication received was: > > * The policy as written allows ARIN to issue a /20 to an ISP only. > However, section 4.3.4. "Additional Considerations" of the End User > Policy in the NRPM states that "End-users may qualify for address > space > under other policies such as Immediate need [4.2.1.6] or > Micro-allocation [4.4].". In order to be consistent, the Immediate > Need > policy language should be changed to reflect the fact that both > ISPs and > end-users can qualify under this policy. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Mon Feb 26 08:09:50 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 26 Feb 2007 05:09:50 -0800 Subject: [ppml] Fwd: Policy Proposal: Modernization of ISP Immediate Need Policy References: <45E2DBAC.30301@arin.net> Message-ID: <79699495-8875-4920-A66A-5C4375C08471@delong.com> I support this change. It seems a reasonable fine-tuning of the policy to match overall policy as it has evolved over the years. Owen On Feb 22, 2007, at 7:38 PM, Member Services wrote: > ARIN received the following policy proposal. In accordance with > the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being > placed on > ARIN's website. > > The AC will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is presented; > > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, > > 3. Not accept the proposal as a formal policy proposal. > > The AC will review this proposal at their next meeting. If the AC > accepts the proposal, then it will be posted as a formal policy > proposal > to PPML and it will be presented at a Public Policy Meeting. If the AC > does not accept the proposal, then the AC will explain that decision; > and at that time the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Modernization of ISP Immediate Need Policy > > Author: Robert Seastrom > Proposal Version: 1.0 > > Submission Date: 22-Feb-2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > Modify NRPM 4.2.1.6 to read: > If an ISP has an immediate need for address space, and > can provide > justification to show that the address space will be utilized > within 30 > days of the request, ARIN may issue a block of address space, not > larger > than a /16 nor smaller than ARIN's customary minimum allocation, > to that > organization. These cases are exceptional. > Current text of 4.2.1.6: > If an ISP has an immediate need for address space, i.e., > the need > exists the day of the request, ARIN may issue a /20 if the > organization, > such as a new company, shows justification. However, these cases are > exceptional. > Rationale: > ARIN staff and ARIN members have identified a few long- > standing problems > with the Immediate Need policy. This policy proposal attempts to > address the following concerns: > > * The Immediate Need policy only allows ISPs to qualify for a / > 20 worth > of space, when a larger size block may be necessary to provide proper > coverage for the proposed project. An example justifying larger space > is an MSOs for which a /20 is insufficient to put an address block > larger than a /29 or /30 on each CMTS in a metropolitan area). > * Conversely, this policy was written before the > current multi-homed > policy (which allows allocations of /21s and /22s). The Immediate > Need > policy should allow assignment of smaller blocks of space if those are > justified. > * The example used in the Immediate Need policy gives > the impression > that an immediate need must exist the day of the request. This seems > both unfair and unreasonable and should probably be changed to > reflect a > realistic timeframe. Concerns expressed about > the Immediate Need Policy but NOT addressed by > this policy proposal (but addressed in a subsequent policy proposal): > > * The policy as written allows ARIN to issue a /20 to an ISP only. > However, section 4.3.4. "Additional Considerations" of the End User > Policy in the NRPM states that "End-users may qualify for address > space > under other policies such as Immediate need [4.2.1.6] or > Micro-allocation [4.4].". In order to be consistent, the Immediate > Need > policy language should be changed to reflect the fact that both > ISPs and > end-users can qualify under this policy. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From info at arin.net Mon Feb 26 14:28:43 2007 From: info at arin.net (Member Services) Date: Mon, 26 Feb 2007 14:28:43 -0500 Subject: [ppml] Notice of PPML Subscription Invitations and Opt-Out Opportunity Message-ID: <45E334EB.9030806@arin.net> Beginning this month, ARIN will send PPML subscription invitations to all registered designated member representatives (DMRs), Admin POCs, and Tech POCs. We realize some of you subscribed to PPML may manage multiple e-mail addresses. Therefore, the invitation will offer a chance to opt out of receiving future PPML subscription invitations. Please contact Member Services at info at arin.net if you have any questions. Regards, Member Services American Registry for Internet Numbers (ARIN) From jordi.palet at consulintel.es Tue Feb 27 02:46:07 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 27 Feb 2007 15:46:07 +0800 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocation criteria - revised text In-Reply-To: <2DA00C5A2146FB41ABDB3E9FCEBC74C10122D7DE@i2km07-ukbr.domain1.systemhost.net> Message-ID: Agree with the point on the expired draft, but my question is precisely to see if there is interest in rescuing it, as it also seems useful for other cases, as it was made clear in the last ARIN meeting. In fact, it can be seen as a new way for doing the same as RFC1918 in IPv4. The main difference is that in IPv6 you don't need to NAT, because you can use both addressing spaces in the same interface, the "private one" (ULA or ULA-central, depending on the case) and global unicast (for "non-private" communications). Regards, Jordi > De: > Responder a: > Fecha: Thu, 22 Feb 2007 10:22:47 -0000 > Para: > Conversaci?n: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocation > criteria - revised text > Asunto: Re: [ppml] Policy Proposal 2006-7: Changes to IPv6initialallocation > criteria - revised text > >> Quick question. Are those addresses being advertised to >> Internet ? If not, >> you could use ULA-central ? > > There is no such thing. Google shows me that ULA-central is something > that was described in an IETF draft which has since expired. Expired > draft documents are meaningless as far as ARIN policy is concerned. > > On the other hand, RFC 2050 is an IETF Best Practice document that is > the foundation of the entire RIR system. In section 3 "Assignment > Framework" it explicitly states: > > In order for the Internet to scale using existing technologies, use > of regional registry services should be limited to the assignment of > IP addresses for organizations meeting one or more of the following > conditions: > > 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. > > The reference to RFC 1918 is for private networks, i.e. networks that > are under one single administrative control and will never interconnect > with another network. It is also an IPv4 specific concept so it does not > apply to IPv6. > > --Michael Dillon > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.