From bmalpas at csc.com Tue Aug 1 16:03:00 2006 From: bmalpas at csc.com (Brian Malpas) Date: Tue, 1 Aug 2006 16:03:00 -0400 Subject: [ppml] Brian Malpas/GIS/CSC is out on vacation Message-ID: I will be out of the office starting 07/22/2006 and will not return until 08/07/2006. I will respond to your message when I return. If you need immediate assistance, contact Robert Dietz 310-344-0575 From memsvcs at arin.net Mon Aug 7 15:43:17 2006 From: memsvcs at arin.net (Member Services) Date: Mon, 07 Aug 2006 15:43:17 -0400 Subject: [ppml] Deadline for Policy Proposals - 12 August 2006 Message-ID: <44D797D5.6030009@arin.net> The ARIN XVIII Public Policy Meeting will take place 11-12 October 2006 in St. Louis. New policy proposals must be submitted by 23:59 EDT, 12 August 2006, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XVIII 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 Aug 10 15:14:30 2006 From: info at arin.net (Member Serivces) Date: Thu, 10 Aug 2006 15:14:30 -0400 Subject: [ppml] New E-mail Address for ARIN Member Services Message-ID: <44DB8596.4080402@arin.net> The Member Services Department of the American Registry for Internet Numbers (ARIN) has changed its e-mail address to info at arin.net. Messages posted to the arin-announce and ppml mailing lists will be sent from info at arin.net. The entire community can use this e-mail address to contact ARIN staff about: - ARIN membership - Designated member representative (DMR) updates - Elections - ARIN meetings, including sponsorship opportunities - General questions about ARIN For information on how to contact ARIN about other issues of concern, please see the Contact Us page at: http://www.arin.net/about_us/contact_us.html Messages sent to our old address (memsvcs at arin.net) will be forwarded for a period of three months. The account will then become inactive, so please update your address book. Member Services will continue to respond to messages in a timely manner and remains committed to serving the needs of the Internet community. Regards, Member Services Department American Registry for Internet Numbers (ARIN) From ras at e-gerbil.net Fri Aug 11 16:34:23 2006 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 11 Aug 2006 16:34:23 -0400 Subject: [ppml] ARIN requiring corporate paperwork for an orgid? Message-ID: <20060811203423.GC12298@overlord.e-gerbil.net> So I'll admit its been a while since I've had to do paperwork as a "new user" of ARIN, but recently I helped somone submit an OrgID registration so that they could more easily manage a couple of SWIPs, and got back: > Please provide either: > > - a URL to a state or province database showing the > specified organization name is a registered business. > > OR > > - a fax to ARIN with a copy of your Articles of Incorporation, a copy > of your state charter, or your business license. Please note > ARIN may ask you for additional information including (but not limited > to) a copy of your business license, your federal or state tax ID, > Dun & Bradstreet information, etc. At what point did ARIN start requiring you to submit documentation on your corporate status to get an OrgID? We're not even talking about entering into a direct relationship with ARIN (e.g. obtaining an ASN or direct IP space), an OrgID is just a record in the whois DB that makes managing resources and contact information easier. In this case, it is to receive a SWIP. Was there a policy change regarding this that I missed? The closest thing I see on the website is http://www.arin.net/policy/proposals/2003_16.html, but this is quite clearly marked as Abandoned. Under what policy does ARIN conduct this verification, and is it really the best use of their time and resources? I'm having a hard time picturing any value gained from this. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From kloch at hotnic.net Fri Aug 11 23:42:48 2006 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 11 Aug 2006 23:42:48 -0400 Subject: [ppml] ARIN requiring corporate paperwork for an orgid? In-Reply-To: <20060811203423.GC12298@overlord.e-gerbil.net> References: <20060811203423.GC12298@overlord.e-gerbil.net> Message-ID: <44DD4E38.1090304@hotnic.net> They've been doing that for at least three years if you try to create an org ID with the Org template. Since Org ID isn't a required field on the SWIP templates you can probably have one created as a side effect of the SWIP processing without the hassle. In that case they might assume that you have done the verification already. I could understand doing this kind of due dilligence on transfer requests but it does seem excessive for simple delegations. Hovever that doesn't bother me as much as the prohibition against P.O. Boxes. What is the rationale behind that? Why is it necessary to have the street address of sensitive facilities (frequently datacenters or even private residences) be published? - Kevin Richard A Steenbergen wrote: > So I'll admit its been a while since I've had to do paperwork as a "new > user" of ARIN, but recently I helped somone submit an OrgID registration > so that they could more easily manage a couple of SWIPs, and got back: > > >>Please provide either: >> >> - a URL to a state or province database showing the >> specified organization name is a registered business. >> >> OR >> >> - a fax to ARIN with a copy of your Articles of Incorporation, a copy >> of your state charter, or your business license. Please note >> ARIN may ask you for additional information including (but not limited >> to) a copy of your business license, your federal or state tax ID, >> Dun & Bradstreet information, etc. > > > At what point did ARIN start requiring you to submit documentation on your > corporate status to get an OrgID? We're not even talking about entering > into a direct relationship with ARIN (e.g. obtaining an ASN or direct IP > space), an OrgID is just a record in the whois DB that makes managing > resources and contact information easier. In this case, it is to receive a > SWIP. > > Was there a policy change regarding this that I missed? The closest thing > I see on the website is http://www.arin.net/policy/proposals/2003_16.html, > but this is quite clearly marked as Abandoned. Under what policy does ARIN > conduct this verification, and is it really the best use of their time and > resources? I'm having a hard time picturing any value gained from this. > From dr at cluenet.de Sun Aug 13 07:52:25 2006 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 13 Aug 2006 13:52:25 +0200 Subject: [ppml] ARIN requiring corporate paperwork for an orgid? In-Reply-To: <20060811203423.GC12298@overlord.e-gerbil.net> References: <20060811203423.GC12298@overlord.e-gerbil.net> Message-ID: <20060813115225.GA11637@srv01.cluenet.de> On Fri, Aug 11, 2006 at 04:34:23PM -0400, Richard A Steenbergen wrote: > At what point did ARIN start requiring you to submit documentation on your > corporate status to get an OrgID? Bonus question: why are only businesses regarded as organizations? Best regards, daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From bicknell at ufp.org Sun Aug 13 18:50:05 2006 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 13 Aug 2006 18:50:05 -0400 Subject: [ppml] SWIP & A trip down memory lane. Message-ID: <20060813225005.GA96593@ussenterprise.ufp.org> Having tried several google searches with no luck, perhaps someone with a better memory can help me. When did SWIP first become available? When was it first required (if a different date). Bonus points for providing links to list archives showing the announcements. -- 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 bmanning at vacation.karoshi.com Sun Aug 13 21:29:51 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 14 Aug 2006 01:29:51 +0000 Subject: [ppml] SWIP & A trip down memory lane. In-Reply-To: <20060813225005.GA96593@ussenterprise.ufp.org> References: <20060813225005.GA96593@ussenterprise.ufp.org> Message-ID: <20060814012951.GA9632@vacation.karoshi.com.> do swip's that pre-date ARIN count? --bill On Sun, Aug 13, 2006 at 06:50:05PM -0400, Leo Bicknell wrote: > > Having tried several google searches with no luck, perhaps someone > with a better memory can help me. > > When did SWIP first become available? When was it first required > (if a different date). Bonus points for providing links to list > archives showing the announcements. > > -- > 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 > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Mon Aug 14 06:06:24 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 14 Aug 2006 11:06:24 +0100 Subject: [ppml] SWIP & A trip down memory lane. In-Reply-To: <20060813225005.GA96593@ussenterprise.ufp.org> Message-ID: Have you seen this? http://www.cctec.com/maillists/nanog/historical/9505/msg00087.html I believe that is the document that was stored at: ftp://rs.internic.net/policy/internic-ip-1.txt However, this is earlier and provides the names of people who were involved at the time. If you recognize any of the names, you could direct your question to someone who was there ;-) http://ftp.univie.ac.at/netinfo/ietf/92jul/swip-minutes-92jul.txt If you are looking for the origins of whois, it goes back even further and probably predates SRI-NIC. However, I'm not sure if documents of those early days are available on the net. --Michael Dillon From Lee.Howard at stanleyassociates.com Mon Aug 14 11:26:53 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 14 Aug 2006 11:26:53 -0400 Subject: [ppml] ARIN requiring corporate paperwork for an orgid? Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB402EAFB58@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Daniel Roesen > Sent: Sunday, August 13, 2006 7:52 AM > To: ppml at arin.net > Subject: Re: [ppml] ARIN requiring corporate paperwork for an orgid? > > On Fri, Aug 11, 2006 at 04:34:23PM -0400, Richard A Steenbergen wrote: > > At what point did ARIN start requiring you to submit > documentation on your > > corporate status to get an OrgID? > > Bonus question: why are only businesses regarded as organizations? Where do you see that? Lee > > > Best regards, > daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From Lee.Howard at stanleyassociates.com Mon Aug 14 11:30:35 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 14 Aug 2006 11:30:35 -0400 Subject: [ppml] ARIN requiring corporate paperwork for an orgid? Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB402EAFB66@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Kevin Loch > Sent: Friday, August 11, 2006 11:43 PM > To: Richard A Steenbergen > Cc: ppml at arin.net > Subject: Re: [ppml] ARIN requiring corporate paperwork for an orgid? > > Hovever that doesn't bother me as much as the prohibition against P.O. > Boxes. What is the rationale behind that? Why is it necessary to have > the street address of sensitive facilities (frequently datacenters or > even private residences) be published? What is the purpose of Whois? Lee > > - Kevin From kloch at hotnic.net Mon Aug 14 12:43:07 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 14 Aug 2006 12:43:07 -0400 Subject: [ppml] ARIN requiring corporate paperwork for an orgid? In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB402EAFB66@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB402EAFB66@CL-S-EX-1.stanleyassociates.com> Message-ID: <44E0A81B.8040604@hotnic.net> Howard, W. Lee wrote: > > What is the purpose of Whois? > I have used it to contact other networks. A PO box should not compromise that functionality in any way. Is there another purpose where it does? For comparison, the FCC allows PO boxes to be used for part 97 license addresses. They do require that they are able to contact you via mail in a timely manner and that you keep the address up to date. - Kevin From packetgrrl at gmail.com Mon Aug 14 13:12:57 2006 From: packetgrrl at gmail.com (cja@daydream.com) Date: Mon, 14 Aug 2006 11:12:57 -0600 Subject: [ppml] ARIN requiring corporate paperwork for an orgid? In-Reply-To: <44E0A81B.8040604@hotnic.net> References: <369EB04A0951824ABE7D8BAC67AF9BB402EAFB66@CL-S-EX-1.stanleyassociates.com> <44E0A81B.8040604@hotnic.net> Message-ID: I live in a part of the world where you have to put a P. O. box because there is no local postal mail delivery. So if I put my company's street address all USPS mail sent to the street address will get returned to sender. Well sometimes boxes get through but it takes weeks and it's a pain. If a street address is required that's fine but there should be a street address and a mailing address. They are not always the same out here in the boonies. ---Cathy On 8/14/06, Kevin Loch wrote: > > Howard, W. Lee wrote: > > > > What is the purpose of Whois? > > > > I have used it to contact other networks. A PO box should not > compromise that functionality in any way. Is there another > purpose where it does? > > For comparison, the FCC allows PO boxes to be used for part 97 > license addresses. They do require that they are able to contact > you via mail in a timely manner and that you keep the address > up to date. > > - Kevin > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Aug 16 12:18:06 2006 From: info at arin.net (Member Services) Date: Wed, 16 Aug 2006 12:18:06 -0400 Subject: [ppml] ARIN XVIII Meeting Registration Open Message-ID: <44E3453E.7040207@arin.net> ARIN would like to invite you to attend the ARIN XVIII Public Policy and Members Meeting, to be held 11-13 October 2006 in St. Louis, Missouri. The meeting will be held back-to-back with NANOG 38 at the Adam's Mark St. Louis Hotel. Previous back-to-back meetings have proven to be excellent opportunities for involvement in both organizations and we look forward to even greater success and participation this fall. Registration for ARIN XVIII is now open. Links to meeting and remote participation information, as well as other meeting information is available at http://www.arin.net/ARIN-XVIII/. 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 XVIII Overview * Sunday, 8 October - NANOG and ARIN attendees are invited to attend "Networking with IPv6," a hands-on workshop focusing on providing experience using IPv6 over a network * Tuesday, 10 October - Evening ARIN tutorial "PKI: An Operational Perspective," and the Open Policy Hour * Wednesday, 11 October - ARIN Public Policy Meeting, Day 1, First Timer Luncheon, evening ARIN Social * Thursday, 12 October - ARIN Public Policy Meeting, Day 2 * Friday, 13 October - ARIN Members Meeting (open to all ARIN XVIII attendees) Additional agenda details and more information about ARIN XVIII 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 From ipgoddess at gmail.com Mon Aug 21 16:43:06 2006 From: ipgoddess at gmail.com (Stacy Taylor) Date: Mon, 21 Aug 2006 13:43:06 -0700 Subject: [ppml] Staff Objections to Policy Proposal 2006-2 Message-ID: <1c16a4870608211343s6cafdfc7g407b8e16670540b1@mail.gmail.com> Hi All! In preparation for St. Louis, the authors and I have reviewed what we believe to be the objections to 2006-2. We took the ARIN staff comments very seriously, The new iteration of the policy does not contain the sections referenced in the first five bullets of the Staff Comment slide, ( found here: http://www.arin.net/meetings/minutes/ARIN_XVII/PDF/tuesday/2006-2-intro.pdf). We do believe that these comments need to be addressed, as they reference existing text in the NRPM, but they are no longer germane to the policy as it is now written. The last bullet point references viable justification of a request submitted under this policy. The authors have posted a very detailed justification about why a microallocation would be required in this one very specific instance. An applicant would need to demonstrate the reconvergence lag to qualify. -- :):) /S From marla.azinger at frontiercorp.com Mon Aug 21 16:36:53 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 21 Aug 2006 16:36:53 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DC62@nyrofcs2ke2k01.corp.pvt> Jason, or whomever may know the answer to these quesions. 1. Does anyone know if this is an ISP and Network Provider wide problem? Or is it more specific to certain ISP's or Networks that set their network up a certain way, or with a specific set of vendor equipment? 2. I assume since this isnt offered as a solution it wont work, but could someone briefly explain why "V6 Private Space" wont work for this. And when I say V6 private space I mean using the Site Local configuration/ address format. Thank you for the clarification Marla Frontier Communications From bmanning at vacation.karoshi.com Mon Aug 21 18:11:09 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 21 Aug 2006 22:11:09 +0000 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DC62@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A01A3DC62@nyrofcs2ke2k01.corp.pvt> Message-ID: <20060821221109.GA15556@vacation.karoshi.com.> On Mon, Aug 21, 2006 at 04:36:53PM -0400, Azinger, Marla wrote: > Jason, or whomever may know the answer to these quesions. > > 1. Does anyone know if this is an ISP and Network Provider wide problem? Or is it more specific to certain ISP's or Networks that set their network up a certain way, or with a specific set of vendor equipment? > > 2. I assume since this isnt offered as a solution it wont work, but could someone briefly explain why "V6 Private Space" wont work for this. And when I say V6 private space I mean using the Site Local configuration/ address format. well that might be tough, since site-local has been depricated, however, sites can use ULA prefixes w/o fear, since the IETF has carved out some unicast space as a free-for-all space... no RIR involvement is possible. Just carve out what you want/need and go with it!!! --bill > > Thank you for the clarification > Marla > Frontier Communications > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Tue Aug 22 04:26:35 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 22 Aug 2006 09:26:35 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <20060821221109.GA15556@vacation.karoshi.com.> Message-ID: > well that might be tough, since site-local has been depricated, > however, sites can use ULA prefixes w/o fear, since the IETF > has carved out some unicast space as a free-for-all space... > no RIR involvement is possible. Just carve out what you want/need > and go with it!!! Officially there is no such thing as ULA. There are no RFCs which reference this. On the other hand, there is an RFC 4193 which seems appropriate. http://www.ietf.org/rfc/rfc4193.txt When educating people, it pays to double check your facts and make sure that your terminology is clear. So, given that RFC 4193 exists, should 2006-2 be changed in some way? Should 2006-2 explicitly refer to RFC 4193? --Michael Dillon From stephen at sprunk.org Tue Aug 22 11:38:00 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 22 Aug 2006 10:38:00 -0500 Subject: [ppml] question on 2006-2 v6 internal microallocation References: Message-ID: <00bb01c6c601$c2a72a40$6401a8c0@atlanta.polycom.com> Thus spake >> well that might be tough, since site-local has been depricated, >> however, sites can use ULA prefixes w/o fear, since the IETF >> has carved out some unicast space as a free-for-all space... >> no RIR involvement is possible. Just carve out what you want/need >> and go with it!!! > > Officially there is no such thing as ULA. There are no > RFCs which reference this. > > On the other hand, there is an RFC 4193 which seems > appropriate. http://www.ietf.org/rfc/rfc4193.txt > > When educating people, it pays to double check your > facts and make sure that your terminology is clear. RFC 4193 addresses are commonly referred to, both in and out of the IPv6 WG, as ULAs. Perhaps the acronym isn't clear, since it doesn't actually appear in the RFC, but it is arguably correct. > So, given that RFC 4193 exists, should 2006-2 be > changed in some way? Should 2006-2 explicitly refer > to RFC 4193? That depends if the intent of 2006-2 was to address hosts that could be accessed from outside the AS or not. If no, then 2006-2 should be killed and/or replaced with a policy telling people to use RFC 4193 ULAs. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From kloch at hotnic.net Tue Aug 22 13:48:11 2006 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 22 Aug 2006 13:48:11 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <00bb01c6c601$c2a72a40$6401a8c0@atlanta.polycom.com> References: <00bb01c6c601$c2a72a40$6401a8c0@atlanta.polycom.com> Message-ID: <44EB435B.4090309@hotnic.net> Stephen Sprunk wrote: > That depends if the intent of 2006-2 was to address hosts that could be > accessed from outside the AS or not. If no, then 2006-2 should be > killed and/or replaced with a policy telling people to use RFC 4193 > ULAs. One of the benefits of 2006-2 vs ULA is that public reverse dns delegations are possible. This is important if they will be used to number non-loopback router interfaces. - Kevin From marla.azinger at frontiercorp.com Mon Aug 21 18:05:23 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 21 Aug 2006 18:05:23 -0400 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DC63@nyrofcs2ke2k01.corp.pvt> This is an update on the status of 2006-1 and also a "nudge" to try and start discussion again. 1. This proposal was voted on by the community and requests for changes to the proposal were made. 2. The ARIN Advisory Council voted on this proposal and took the community input into consideration. Thus the proposal was voted to move forward given the author would work on revising the proposal with the community input. 3. The author of this proposal has now chosen not to take the community input and will not be revising the proposal. Instead the author will be proposing this proposal again unchanged. 4. We the Advisory Council understand that we are asking you to restate the same comments that you already had in the past. We value your time and input and ask that you please once again, state your constructive suggestions. Now, lets get the ball rolling again. Here are three of the previouse suggestions. Please add, adjust and reply to them. Thank you Suggested Solutions: 1. For residential only allow PO box info or the upstream address. Regardless of the size. Contigency plan should this policy result in Abuse issues: If a pattern shows that the internet community is having issues with a certain subnet size and abuse with residential customers...then in the future a vote to modify the proposal and add subnet size that requires exact address will be executed. 2. For Residential only a non specific zip code will be utilized. Contingency plan should this policy result in privacy problems: If a pattern shows that the internet community is having privacy issues then in the future a vote to insert address info of the internet provider in lue of the residential user will be executed. On Topic Opinions: 1. I believe the current Residential Policy is satisfactory and should be left unchanged. If someone has security risks then the information in ARIN WHOIS is the least of their problem as to where sensitive information can be easily accessed on the internet. 2. I believe everyone should be allowed to privacy. But does it have to include everyone? Or just those that have a proven security issue? 3. Everyone should be allowed to have privacy. 4. Everyone should have to show what IP addresses they are using and who they are. From marla.azinger at frontiercorp.com Tue Aug 22 12:42:48 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Tue, 22 Aug 2006 12:42:48 -0400 Subject: [ppml] 2006-1 Residential Customer Privacy Update Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A42BB3@nyrofcs2ke2k01.corp.pvt> This is an update on the status of 2006-1 and also a "nudge" to try and start discussion again. 1. This proposal was voted on by the community and requests for changes to the proposal were made. 2. The ARIN Advisory Council voted on this proposal and took the community input into consideration. Thus the proposal was voted to move forward given the author would work on revising the proposal with the community input. 3. The author of this proposal has now chosen not to take the community input and will not be revising the proposal. Instead the author will be proposing this proposal again unchanged. 4. We the Advisory Council understand that we are asking you to restate the same comments that you already had in the past. We value your time and input and ask that you please once again, state your constructive suggestions. Now, lets get the ball rolling again. Here are three of the previouse suggestions. Please add, adjust and reply to them. Thank you Suggested Solutions: 1. For residential only allow PO box info or the upstream address. Regardless of the size. Contigency plan should this policy result in Abuse issues: If a pattern shows that the internet community is having issues with a certain subnet size and abuse with residential customers...then in the future a vote to modify the proposal and add subnet size that requires exact address will be executed. 2. For Residential only a non specific zip code will be utilized. Contingency plan should this policy result in privacy problems: If a pattern shows that the internet community is having privacy issues then in the future a vote to insert address info of the internet provider in lue of the residential user will be executed. On Topic Opinions: 1. I believe the current Residential Policy is satisfactory and should be left unchanged. If someone has security risks then the information in ARIN WHOIS is the least of their problem as to where sensitive information can be easily accessed on the internet. 2. I believe everyone should be allowed to privacy. But does it have to include everyone? Or just those that have a proven security issue? 3. Everyone should be allowed to have privacy. 4. Everyone should have to show what IP addresses they are using and who they are. From schiller at uu.net Tue Aug 22 17:02:37 2006 From: schiller at uu.net (Jason Schiller) Date: Tue, 22 Aug 2006 17:02:37 -0400 (EDT) Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <44EB435B.4090309@hotnic.net> Message-ID: Public reverse dns is important for all interfaces on the router including loopbacks. This is true in cases where the address is both publicly reachable and in cases where the address is not publicly reachable for reasons of troubleshooting, fault isolation, traceroute, ping, ssh, etc. ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Tue, 22 Aug 2006, Kevin Loch wrote: > Date: Tue, 22 Aug 2006 13:48:11 -0400 > From: Kevin Loch > To: ppml at arin.net > Subject: Re: [ppml] question on 2006-2 v6 internal microallocation > > Stephen Sprunk wrote: > > That depends if the intent of 2006-2 was to address hosts that could be > > accessed from outside the AS or not. If no, then 2006-2 should be > > killed and/or replaced with a policy telling people to use RFC 4193 > > ULAs. > > One of the benefits of 2006-2 vs ULA is that public reverse dns > delegations are possible. This is important if they will be used to > number non-loopback router interfaces. > > - Kevin > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From schiller at uu.net Tue Aug 22 17:09:25 2006 From: schiller at uu.net (Jason Schiller) Date: Tue, 22 Aug 2006 17:09:25 -0400 (EDT) Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <00bb01c6c601$c2a72a40$6401a8c0@atlanta.polycom.com> Message-ID: The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Tue, 22 Aug 2006, Stephen Sprunk wrote: > RFC 4193 addresses are commonly referred to, both in and out of the IPv6 > WG, as ULAs. Perhaps the acronym isn't clear, since it doesn't actually > appear in the RFC, but it is arguably correct. > > > So, given that RFC 4193 exists, should 2006-2 be > > changed in some way? Should 2006-2 explicitly refer > > to RFC 4193? > > That depends if the intent of 2006-2 was to address hosts that could be > accessed from outside the AS or not. If no, then 2006-2 should be > killed and/or replaced with a policy telling people to use RFC 4193 > ULAs. > RFC 4193 ULAs do not insure global uniqueness, nor do they offer an outside authority that documents if a given organization has a legitimate claim to use a specific address in the event of a collision. We need a mechanism to guarantee global uniqueness between us and our managed customer networks. ___Jason From owen at delong.com Tue Aug 22 17:44:06 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Aug 2006 14:44:06 -0700 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DC63@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A01A3DC63@nyrofcs2ke2k01.corp.pvt> Message-ID: <0856A8CB-515D-4261-A40E-03BA2D02A866@delong.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A residential customer should, in all cases, have the option of publishing their information as any other internet user. The option of hiding residential address is not unreasonable, however, at the least, city, state, and non-specific postal code should be preserved (5- digit ZIP (US), first 3 characters of Canadian Postal Code, or equivalant). Realistically, more information than this is a matter of public record if the customer has registered to vote. Owen On Aug 21, 2006, at 3:05 PM, Azinger, Marla wrote: > This is an update on the status of 2006-1 and also a "nudge" to try > and start discussion again. > > 1. This proposal was voted on by the community and requests for > changes to the proposal were made. > > 2. The ARIN Advisory Council voted on this proposal and took the > community input into consideration. Thus the proposal was voted to > move forward given the author would work on revising the proposal > with the community input. > > 3. The author of this proposal has now chosen not to take the > community input and will not be revising the proposal. Instead the > author will be proposing this proposal again unchanged. > > 4. We the Advisory Council understand that we are asking you to > restate the same comments that you already had in the past. We > value your time and input and ask that you please once again, state > your constructive suggestions. > > > Now, lets get the ball rolling again. Here are three of the > previouse suggestions. Please add, adjust and reply to them. > Thank you > > Suggested Solutions: > > 1. For residential only allow PO box info or the upstream > address. Regardless of the size. > > Contigency plan should this policy result in Abuse issues: If a > pattern shows that the internet community is having issues with a > certain subnet size and abuse with residential customers...then in > the future a vote to modify the proposal and add subnet size that > requires exact address will be executed. > > > 2. For Residential only a non specific zip code will be utilized. > > Contingency plan should this policy result in privacy problems: If > a pattern shows that the internet community is having privacy > issues then in the future a vote to insert address info of the > internet provider in lue of the residential user will be executed. > > > On Topic Opinions: > > 1. I believe the current Residential Policy is satisfactory and > should be left unchanged. If someone has security risks then the > information in ARIN WHOIS is the least of their problem as to where > sensitive information can be easily accessed on the internet. > > 2. I believe everyone should be allowed to privacy. But does it > have to include everyone? Or just those that have a proven > security issue? > > 3. Everyone should be allowed to have privacy. > > 4. Everyone should have to show what IP addresses they are using > and who they are. > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE63qnn5zKWQ/iqj0RAhbOAJ9J0fiOaAgCUGSz+ukBQ+vXP/a9lgCeKIDp 6hPIpLvb9W8A8e8OJwJFLLc= =Vifw -----END PGP SIGNATURE----- From Michael.Dillon at btradianz.com Wed Aug 23 04:45:16 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 23 Aug 2006 09:45:16 +0100 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DC63@nyrofcs2ke2k01.corp.pvt> Message-ID: > This is an update on the status of 2006-1 and also a "nudge" to try > and start discussion again. > Suggested Solutions: 3. Remove all address and contact information from published whois directory data that was NOT received directly from the party in question. In other words, only publish whois directory address and contact info for those organizations which have a direct relationship with ARIN. At a minimum, all recipients of allocations (or any ARIN assignments) would be required to publish address and contact info regardless of whether they originally got their allocation from SRI-NIC, InterNIC or IANA. But anyone who gets an assignment from their ISP has the **OPTION** of directly contacting ARIN and asking for their contact info to be published. This creates a direct relationship with ARIN that can be used to ensure that the information is correct. Basically, an entry is correct when it will reach a person who is ready, willing and able to communicate regarding network operations and interconnect issues and who is able to act on that communication. Any other organizations may elect to be listed in the whois. Any other data is useless rubbish which should not be published in a directory, WHOIS or otherwise. > 3. Everyone should be allowed to have privacy. Yes, everyone should be allowed to have privacy whether they are a residential customer or not. There is no good reason for publishing the bulk of the info in the whois directory. It is a holdover from the days of the ARPANET when every ARPANET user had to be identified for budgetary purposes. We are no longer running the ARPANET and there is no longer the budgetary mandate that requires us to collect and publish this info. The only reason we do this is tradition, like the cargo cults in the Pacific Islands that worship airplane models made of rattan and bamboo because they don't understand that World War II is over and the planes with free food and trinkets won't be coming back. --Michael Dillon From Michael.Dillon at btradianz.com Wed Aug 23 04:53:12 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 23 Aug 2006 09:53:12 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: Message-ID: > RFC 4193 ULAs do not insure global uniqueness, nor do they offer an > outside authority that documents if a given organization has a legitimate > claim to use a specific address in the event of a collision. > > We need a mechanism to guarantee global uniqueness between us and our > managed customer networks. We are in the same position. In addition, we operate a global internetwork that is disjoint from the public Internet. Nevertheless, it is an internetwork connecting over 10,000 sites from well over a thousand different organizations. There the requirement for globally unique registered addresses is exactly the same as the Internet requirement. Given that v6 has the address space available, I don't see why the reticence to allow for microallocations. I can guarantee that any prefixes in our global routing table will have zero impact on the public Internet routing table because as a matter of policy we do not allow routes to be exchanged with the public Internet. And I believe there are several other such global Internets in existence, perhaps as many as a dozen. IP addresses, v6 or otherwise, are not the exclusive property of the public Internet. They belong to everybody who uses the Internet Protocol (IP) regardless of whether they exchange routes on the public network. --Michael Dillon From Michael.Dillon at btradianz.com Wed Aug 23 04:58:19 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 23 Aug 2006 09:58:19 +0100 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <0856A8CB-515D-4261-A40E-03BA2D02A866@delong.com> Message-ID: > Realistically, more information than this is a matter of public > record if the customer has registered > to vote. Have you checked this assertion with Elections Canada? In any case, I believe that even the name of the person receiving the assignment should be UNPUBLISHED. If the ISP is willing to assert that the address block is assigned to an active customer then that is good enough for me. The ISP is responsible for that address range unless they delegate the responsibility to a customer. In this context, delegate means that they contractually require the customer to take responsibility and publish contact information. In my opinion, all assignments should be treated equal. There is no need for special treatment for residential customers if the overall policy satisfies Canadian and US privacy legislation. An overall policy is simpler to administer from ARIN's point of view. --Michael Dillon From jb at jbacher.com Wed Aug 23 09:40:47 2006 From: jb at jbacher.com (J Bacher) Date: Wed, 23 Aug 2006 08:40:47 -0500 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <0856A8CB-515D-4261-A40E-03BA2D02A866@delong.com> References: <454810F09B5AA04E9D78D13A5C39028A01A3DC63@nyrofcs2ke2k01.corp.pvt> <0856A8CB-515D-4261-A40E-03BA2D02A866@delong.com> Message-ID: <44EC5ADF.30109@jbacher.com> Owen DeLong wrote: > A residential customer should, in all cases, have the option of > publishing their information as any other > internet user. The option of hiding residential address is not > unreasonable, however, at the least, > city, state, and non-specific postal code should be preserved (5- > digit ZIP (US), first 3 characters This is not reasonable for those in low population dense areas. > Realistically, more information than this is a matter of public > record if the customer has registered to vote. Realistically, a lot of people aren't registered to vote. If the upstream ISP is willing to assume responsibility, the need to publish the assignment address is not necessary. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dlw+arin at tellme.com Wed Aug 23 10:26:23 2006 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 23 Aug 2006 07:26:23 -0700 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: References: Message-ID: <20060823142623.GU18486@shell01.corp.tellme.com> On Wed, Aug 23, 2006 at 09:53:12AM +0100, Michael.Dillon at btradianz.com wrote: > > RFC 4193 ULAs do not insure global uniqueness, nor do they offer an > > outside authority that documents if a given organization has a > legitimate > > claim to use a specific address in the event of a collision. > > > > We need a mechanism to guarantee global uniqueness between us and our > > managed customer networks. > > We are in the same position. In addition, we operate a global > internetwork that is disjoint from the public Internet. Nevertheless, > it is an internetwork connecting over 10,000 sites from well over > a thousand different organizations. There the requirement for > globally unique registered addresses is exactly the same as the > Internet requirement. It's also worth noting that some networks attached to private internetworks may also have an attachement to the public Internet, which makes further demands on unqiue addressing, even when many of the routes are nto exposed to the public Internet. I have a customer that decided to ignore global uniqueness in IPv4 space, since their network doesn't touch the Internet. That's all well and good, except I have to exchange data with them *and* the public Internet. That's rather troublesome when they've decided to just use random space in IPv4. (At present, it's still in IANA reserved space. That won't be true at some point, and then it gets "exciting".) global uniqueness, even for non-attached networks, is a vital rquirement. I don't understand the concerns with microallocations either. I think Jason has outlined a serious problem. If you use BGP, this is an issue. I'd probably be in favor of a policy that hands out a /48 for this purpose when you get an AS. (A numbering scheme that makes the allocation identifiable with the AS would be ideal.) Finally, let's be honest: most organizations aren't going to consume a /48 very quickly, if ever. We're handing out gigantic chunks of network space. If the concern here is wastefulness, we should step back and contemplate more than two allocation sizes (huge, i.e., /32, and "micro", at /48). If we're worried about consumption, let's hand out blocks of a size that makes sense for an organization. This really feels like were repeating the mistakes of the past. -David From Michael.Dillon at btradianz.com Wed Aug 23 10:47:07 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 23 Aug 2006 15:47:07 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <20060823142623.GU18486@shell01.corp.tellme.com> Message-ID: > It's also worth noting that some networks attached to private > internetworks may also have an attachement to the public Internet, > which makes further demands on unqiue addressing, even when many of the > routes are nto exposed to the public Internet. Yes, in fact we could say that *ALL* organizations who connect to other internetworks also have Internet connections. Sometimes, the organization has a single internal network and controls traffic flow using routing policy and firewalls. In other cases, an airgap is enforced. It all depends on which other internetwork is involved and how much importance is given to multiple layers of security. > That's rather > troublesome when they've decided to just use random space in IPv4. (At > present, it's still in IANA reserved space. That won't be true at some > point, and then it gets "exciting".) global uniqueness, even for > non-attached networks, is a vital rquirement. I know one company that built global internetworks and used the same set of "random" IPv4 addresses in each one since they were all "separate". There were at least three global IP internetworks using 1/8 addresses. In the vast IPv6 address space, globally unique addressing should be easy to achieve for everyone who needs it. We just have to make the policies fit the real world needs. > I don't understand the concerns with microallocations either. I think > Jason has outlined a serious problem. If you use BGP, this is an > issue. I'd probably be in favor of a policy that hands out a /48 for > this purpose when you get an AS. (A numbering scheme that makes the > allocation identifiable with the AS would be ideal.) One could envision a special class of AS number, using the extended 32-bit AS numbers, which would come with an IPv6 /48 block attached in much the same way that 16-bit AS numbers come with a block of IPv4 multicast space attached to them. > This really feels > like were repeating the mistakes of the past. It is hard to get people to see that the networking world of today is vastly different from the 80s and 90s. Take multicast for instance. People thought that this would enable a kind of Internet video broadcasting. Instead, the main use of multicast is to deliver the live stock market data that used to be delivered over ticker-tape machines. --Michael Dillon From schiller at uu.net Wed Aug 23 12:43:00 2006 From: schiller at uu.net (Jason Schiller) Date: Wed, 23 Aug 2006 12:43:00 -0400 (EDT) Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: Message-ID: Michael, I have two questions for you: 1. Are you in favor or opposed to this policy? 2. You mention that you can guarantee that there will be zero impact on the public Internet routing table. The original policy had some text saying that this micro-allocation MUST not be routed. But there were objections about ARIN not setting routing policy. So this text was completely dropped from the current policy proposal. We considered softening this statemet to something like: This micro-allocation should not be routed. Or It is intended that this allocation should not be routed. One post on ppml last spring suggested that the language should be strengthened to be some thing like: This micro-allocation MUST not be routed. If an organization is found to be routing their micro-allocation for internal infrastructure they must either correct this mistake or surrender thier micro-allocation for internal infrastructure. Do you think 2006-2 is better with or without text on if the micro-allocation for internal infrastructure should not be routed in the global Internet? If you think text should be added to 2006-2 about routing this space, do you prefer weaker or stronger text? Comments for others are also welcomed. Thanks, __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Wed, 23 Aug 2006 Michael.Dillon at btradianz.com wrote: > Date: Wed, 23 Aug 2006 09:53:12 +0100 > From: Michael.Dillon at btradianz.com > To: ppml at arin.net > Subject: Re: [ppml] question on 2006-2 v6 internal microallocation > > > RFC 4193 ULAs do not insure global uniqueness, nor do they offer an > > outside authority that documents if a given organization has a > legitimate > > claim to use a specific address in the event of a collision. > > > > We need a mechanism to guarantee global uniqueness between us and our > > managed customer networks. > > We are in the same position. In addition, we operate a global > internetwork that is disjoint from the public Internet. Nevertheless, > it is an internetwork connecting over 10,000 sites from well over > a thousand different organizations. There the requirement for > globally unique registered addresses is exactly the same as the > Internet requirement. > > Given that v6 has the address space available, I don't see why > the reticence to allow for microallocations. I can guarantee that > any prefixes in our global routing table will have zero impact > on the public Internet routing table because as a matter of policy > we do not allow routes to be exchanged with the public Internet. > And I believe there are several other such global Internets in > existence, perhaps as many as a dozen. IP addresses, v6 or > otherwise, are not the exclusive property of the public Internet. > They belong to everybody who uses the Internet Protocol (IP) > regardless of whether they exchange routes on the public network. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From bmanning at vacation.karoshi.com Wed Aug 23 17:53:01 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 23 Aug 2006 21:53:01 +0000 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: References: Message-ID: <20060823215301.GA31205@vacation.karoshi.com.> On Wed, Aug 23, 2006 at 12:43:00PM -0400, Jason Schiller wrote: (quoting unnamed sources) > > This micro-allocation MUST not be routed. If an organization is found to > be routing their micro-allocation for internal infrastructure they must > either correct this mistake or surrender thier micro-allocation for > internal infrastructure. > humph... routed -where-? prefixes not routed are effective only in the single broadcast domain where they are used. me thinks this "requirement" is overly broad and screams for the creation of the "routing police". e.g. Geoff and the RIB/FIBettes. eh? i'm in favor of -NOT- having this language. --bill From ipgoddess at gmail.com Wed Aug 23 20:12:32 2006 From: ipgoddess at gmail.com (Stacy Taylor) Date: Wed, 23 Aug 2006 17:12:32 -0700 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <20060823215301.GA31205@vacation.karoshi.com.> References: <20060823215301.GA31205@vacation.karoshi.com.> Message-ID: <1c16a4870608231712t4c11426cx60f2ec59a6f3af69@mail.gmail.com> I likewise think that language should not be in the policy. ARIN AC is as we speak in the process of looking at the NRPM with the possible intention to take out any operational recommendations. Let's not put in what we'll likely wind up taking out down the road. :) Stacy On 8/23/06, bmanning at vacation.karoshi.com wrote: > On Wed, Aug 23, 2006 at 12:43:00PM -0400, Jason Schiller wrote: > (quoting unnamed sources) > > > > This micro-allocation MUST not be routed. If an organization is found to > > be routing their micro-allocation for internal infrastructure they must > > either correct this mistake or surrender thier micro-allocation for > > internal infrastructure. > > > > humph... routed -where-? > prefixes not routed are effective only in the single broadcast domain > where they are used. me thinks this "requirement" is overly broad > and screams for the creation of the "routing police". e.g. > Geoff and the RIB/FIBettes. eh? > > i'm in favor of -NOT- having this language. > > --bill > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -- :):) /S From schiller at uu.net Wed Aug 23 20:43:16 2006 From: schiller at uu.net (Jason Schiller) Date: Wed, 23 Aug 2006 20:43:16 -0400 (EDT) Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <1c16a4870608231712t4c11426cx60f2ec59a6f3af69@mail.gmail.com> Message-ID: Stacy, Bill, Thanks, that is good feed back. The authors of 2006-2 agreed to take out that text in the second attempt, since "ARIN does not set routing policy" But that still leaves part of the question unanswered. Is it worth noting that the intent is that this micro-allocation for critical infrastructure is not intended to be advertised to the global routing table (without trying to set routing policy)? There seems to be some people that can more easliy adopt this policy given that in theory there should be no impact on the global routing table. There is one set of conditions that allow you to qualify for this space, and those conditions prevent you from routing the micro-allocation as an aggregate, thus the routes will never get outside of your routing domain. Just wondering if people find value in that as part of the policy, or is clearly understood? __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Wed, 23 Aug 2006, Stacy Taylor wrote: > Date: Wed, 23 Aug 2006 17:12:32 -0700 > From: Stacy Taylor > To: "bmanning at vacation.karoshi.com" > Cc: Jason Schiller , ppml at arin.net > Subject: Re: Re: [ppml] question on 2006-2 v6 internal microallocation > > I likewise think that language should not be in the policy. ARIN AC > is as we speak in the process of looking at the NRPM with the possible > intention to take out any operational recommendations. > Let's not put in what we'll likely wind up taking out down the road. > :) > Stacy > > On 8/23/06, bmanning at vacation.karoshi.com wrote: > > On Wed, Aug 23, 2006 at 12:43:00PM -0400, Jason Schiller wrote: > > (quoting unnamed sources) > > > > > > This micro-allocation MUST not be routed. If an organization is found to > > > be routing their micro-allocation for internal infrastructure they must > > > either correct this mistake or surrender thier micro-allocation for > > > internal infrastructure. > > > > > > > humph... routed -where-? > > prefixes not routed are effective only in the single broadcast domain > > where they are used. me thinks this "requirement" is overly broad > > and screams for the creation of the "routing police". e.g. > > Geoff and the RIB/FIBettes. eh? > > > > i'm in favor of -NOT- having this language. > > > > --bill > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > > -- > :):) > /S > From pekkas at netcore.fi Thu Aug 24 01:13:59 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 24 Aug 2006 08:13:59 +0300 (EEST) Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: References: Message-ID: On Wed, 23 Aug 2006, Jason Schiller wrote: > But that still leaves part of the question unanswered. Is it worth noting > that the intent is that this micro-allocation for critical infrastructure > is not intended to be advertised to the global routing table (without > trying to set routing policy)? ... > Just wondering if people find value in that as part of the policy, or is > clearly understood? I think putting it in terms of 'advertised' is a bit backwards. Rather, you should ask something like: Do packets legitimately including a source address from this address block ever get sent over the public Internet? (YES/NO) I'm not sure if I'd want to see internal, non-routed infrastructure blocks being used to send packets (e.g., traceroute responses) which cannot be dropped by uRPF and other ingress filtering mechanisms. That aside... I looked at the policy proposal, and the BGP re-convergence rationale seems to be quite odd or outdated. This is exactly the reason why e.g., JunOS supports 'routing-options - resolution - rib FOO - import' configuration. We've used that ourselves for years now and there is no issue with numbering the BGP sessions from the aggregate. I'd suspect Cisco supports similar configuration, or would easily to be fixed to do so. Internal structure considerations also doesn't apply, as your neighbors and customers can static-route to your internal block unless you implement packet filtering at your borders. Hence, I cannot see a scenario where packet filtering wouldn't be sufficient. -- 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 btradianz.com Thu Aug 24 05:04:18 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 24 Aug 2006 10:04:18 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: Message-ID: > 1. Are you in favor or opposed to this policy? I support the policy to give micro-allocations for internal infrastructure. > 2. You mention that you can guarantee that there will be zero impact on > the public Internet routing table. I think you misunderstand. In the past, whenever anyone proposes smaller than normal sized allocations, many people object that this will result in a large number of new entries in the global routing table. I was merely pointing out one situation that exists today where allocations from ARIN or other RIRs do not end up in the global routing table. In other words, there is not a direct relationship between RIR allocations and the number of entries in the public Internet routing table. RIR policies need to support the needs of *ALL* users of Internet Protocol (IP) networking technology, not just the people who peer in the default-free zone of the public Internet. > The original policy had some text saying that this micro-allocation MUST > not be routed. But there were objections about ARIN not setting routing > policy. So this text was completely dropped from the current policy > proposal. Very right. ARIN does not set policy for the routing table and the routing table does not decide ARIN's policies. > Do you think 2006-2 is better with or without text on if the > micro-allocation for internal infrastructure should not be routed in > the global Internet? If you think text should be added to 2006-2 about > routing this space, do you prefer weaker or stronger text? ARIN is not the Internet mummy. Why should ARIN policy say what should or should not be done outside the scope of its authority? On the other hand, there is nothing wrong with the statement: Due to the fact that these address blocks will be used for blahditty-blahditty-blah, it is expected that they will not be announced in the default-free zone of the public Internet. One of ARIN's duties is education and it is entirely appropriate for policies to be clearly written and include explanations of the context in which the policy was created. This is why charters and other such legal documents have something called "the preamble". People have always felt that laws, contracts, and other legal agreements should have a clear context. --Michael Dillon From Michael.Dillon at btradianz.com Thu Aug 24 05:08:16 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 24 Aug 2006 10:08:16 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <1c16a4870608231712t4c11426cx60f2ec59a6f3af69@mail.gmail.com> Message-ID: > ARIN AC > is as we speak in the process of looking at the NRPM with the possible > intention to take out any operational recommendations. I am in favor of NOT having operational recommendations in the NPRM. I am NOT IN FAVOR of removing the existing operational recommendations. I am in favor of rewording such recommendations so that they are OPERATIONAL EXPECTATIONS. Expectations are an important part of the policies because if situations change and the expectations are no longer met, then this is a flag that a particular section of policy needs to be reviewed. --Michael Dillon From schiller at uu.net Thu Aug 24 08:21:05 2006 From: schiller at uu.net (Jason Schiller) Date: Thu, 24 Aug 2006 08:21:05 -0400 (EDT) Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: Message-ID: On Thu, 24 Aug 2006, Pekka Savola wrote: > I looked at the policy proposal, and the BGP re-convergence rationale > seems to be quite odd or outdated. This is exactly the reason why > e.g., JunOS supports 'routing-options - resolution - rib FOO - import' > configuration. We've used that ourselves for years now and there is > no issue with numbering the BGP sessions from the aggregate. I'd > suspect Cisco supports similar configuration, or would easily to be > fixed to do so. Not all vendors currently support this functionality. Cisco only supports this functionality in 12.2 T code. It will take some time for this functionality to show up in code that is useful to large service providers. I am also in the process of working with Cisco on a draft RFC to encourage all vendors to support this functionality. > > Internal structure considerations also doesn't apply, as your > neighbors and customers can static-route to your internal block unless > you implement packet filtering at your borders. Hence, I cannot see a > scenario where packet filtering wouldn't be sufficient. Large scale ISPs require hardware based packet forwarding to due to the high pps requirements in some cases as high as 6Mpps. Currently not all hardware deployed in all large ISPs has the capability to do line rate packet filtering on all ingress interfaces. ___Jason From bmanning at vacation.karoshi.com Fri Aug 25 10:56:47 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 25 Aug 2006 14:56:47 +0000 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: References: <1c16a4870608231712t4c11426cx60f2ec59a6f3af69@mail.gmail.com> Message-ID: <20060825145647.GA10800@vacation.karoshi.com.> where is the "global" routing table defined? is that a universally agreed on definition? answeringthese questions will help answer your questions. --bill On Wed, Aug 23, 2006 at 08:43:16PM -0400, Jason Schiller wrote: > Stacy, Bill, > > Thanks, that is good feed back. The authors of 2006-2 agreed to take out > that text in the second attempt, since "ARIN does not set routing policy" > > But that still leaves part of the question unanswered. Is it worth noting > that the intent is that this micro-allocation for critical infrastructure > is not intended to be advertised to the global routing table (without > trying to set routing policy)? > > There seems to be some people that can more easliy adopt this policy given > that in theory there should be no impact on the global routing > table. There is one set of conditions that allow you to qualify for this > space, and those conditions prevent you from routing the micro-allocation > as an aggregate, thus the routes will never get outside of your routing > domain. > > Just wondering if people find value in that as part of the policy, or is > clearly understood? > > __Jason > > > ========================================================================== > Jason Schiller (703)886.6648 > Senior Internet Network Engineer fax:(703)886.0512 > Public IP Global Network Engineering schiller at uu.net > UUNET / Verizon jason.schiller at verizonbusiness.com > > The good news about having an email address that is twice as long is that > it increases traffic on the Internet. > > On Wed, 23 Aug 2006, Stacy Taylor wrote: > > > Date: Wed, 23 Aug 2006 17:12:32 -0700 > > From: Stacy Taylor > > To: "bmanning at vacation.karoshi.com" > > Cc: Jason Schiller , ppml at arin.net > > Subject: Re: Re: [ppml] question on 2006-2 v6 internal microallocation > > > > I likewise think that language should not be in the policy. ARIN AC > > is as we speak in the process of looking at the NRPM with the possible > > intention to take out any operational recommendations. > > Let's not put in what we'll likely wind up taking out down the road. > > :) > > Stacy > > > > On 8/23/06, bmanning at vacation.karoshi.com wrote: > > > On Wed, Aug 23, 2006 at 12:43:00PM -0400, Jason Schiller wrote: > > > (quoting unnamed sources) > > > > > > > > This micro-allocation MUST not be routed. If an organization is found to > > > > be routing their micro-allocation for internal infrastructure they must > > > > either correct this mistake or surrender thier micro-allocation for > > > > internal infrastructure. > > > > > > > > > > humph... routed -where-? > > > prefixes not routed are effective only in the single broadcast domain > > > where they are used. me thinks this "requirement" is overly broad > > > and screams for the creation of the "routing police". e.g. > > > Geoff and the RIB/FIBettes. eh? > > > > > > i'm in favor of -NOT- having this language. > > > > > > --bill > > > _______________________________________________ > > > PPML mailing list > > > PPML at arin.net > > > http://lists.arin.net/mailman/listinfo/ppml > > > > > > > > > -- > > :):) > > /S > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From marla.azinger at frontiercorp.com Mon Aug 28 12:24:37 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 28 Aug 2006 12:24:37 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DC73@nyrofcs2ke2k01.corp.pvt> If Jason's response is the fact we are facing. It would be good to add some lines into the proposal stating that the intent of this proposal is to be used by those facing these contstraints. I say this only because I believe it is necessary to point out to people why they would or would not qualify for this type of allocation should this proposal pass. I read the proposal as it is currently, and this doesnt seem to be clear enough to me. Thank you Marla Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jason Schiller Sent: Thursday, August 24, 2006 5:21 AM To: Pekka Savola Cc: bmanning at vacation.karoshi.com; ppml at arin.net; Jason Schiller Subject: Re: [ppml] question on 2006-2 v6 internal microallocation On Thu, 24 Aug 2006, Pekka Savola wrote: > I looked at the policy proposal, and the BGP re-convergence rationale > seems to be quite odd or outdated. This is exactly the reason why > e.g., JunOS supports 'routing-options - resolution - rib FOO - import' > configuration. We've used that ourselves for years now and there is > no issue with numbering the BGP sessions from the aggregate. I'd > suspect Cisco supports similar configuration, or would easily to be > fixed to do so. Not all vendors currently support this functionality. Cisco only supports this functionality in 12.2 T code. It will take some time for this functionality to show up in code that is useful to large service providers. I am also in the process of working with Cisco on a draft RFC to encourage all vendors to support this functionality. > > Internal structure considerations also doesn't apply, as your > neighbors and customers can static-route to your internal block unless > you implement packet filtering at your borders. Hence, I cannot see a > scenario where packet filtering wouldn't be sufficient. Large scale ISPs require hardware based packet forwarding to due to the high pps requirements in some cases as high as 6Mpps. Currently not all hardware deployed in all large ISPs has the capability to do line rate packet filtering on all ingress interfaces. ___Jason _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From marla.azinger at frontiercorp.com Mon Aug 28 12:28:48 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 28 Aug 2006 12:28:48 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DC74@nyrofcs2ke2k01.corp.pvt> I dont agree with taking this text out. It isnt ARIN's job to set routing policy. However, it is ARIN's job to clearly stipulate how the IP addresses are to be requested and what the use of them is being granted for. Yes, this walks the line of routing, but realistically, what we do with IP addresses is always going to have "thermal crossover" with routing. Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jason Schiller Sent: Wednesday, August 23, 2006 5:43 PM To: Stacy Taylor Cc: bmanning at vacation.karoshi.com; ppml at arin.net; Jason Schiller Subject: Re: [ppml] question on 2006-2 v6 internal microallocation Stacy, Bill, Thanks, that is good feed back. The authors of 2006-2 agreed to take out that text in the second attempt, since "ARIN does not set routing policy" But that still leaves part of the question unanswered. Is it worth noting that the intent is that this micro-allocation for critical infrastructure is not intended to be advertised to the global routing table (without trying to set routing policy)? There seems to be some people that can more easliy adopt this policy given that in theory there should be no impact on the global routing table. There is one set of conditions that allow you to qualify for this space, and those conditions prevent you from routing the micro-allocation as an aggregate, thus the routes will never get outside of your routing domain. Just wondering if people find value in that as part of the policy, or is clearly understood? __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Wed, 23 Aug 2006, Stacy Taylor wrote: > Date: Wed, 23 Aug 2006 17:12:32 -0700 > From: Stacy Taylor > To: "bmanning at vacation.karoshi.com" > Cc: Jason Schiller , ppml at arin.net > Subject: Re: Re: [ppml] question on 2006-2 v6 internal microallocation > > I likewise think that language should not be in the policy. ARIN AC > is as we speak in the process of looking at the NRPM with the possible > intention to take out any operational recommendations. > Let's not put in what we'll likely wind up taking out down the road. > :) > Stacy > > On 8/23/06, bmanning at vacation.karoshi.com wrote: > > On Wed, Aug 23, 2006 at 12:43:00PM -0400, Jason Schiller wrote: > > (quoting unnamed sources) > > > > > > This micro-allocation MUST not be routed. If an organization is found to > > > be routing their micro-allocation for internal infrastructure they must > > > either correct this mistake or surrender thier micro-allocation for > > > internal infrastructure. > > > > > > > humph... routed -where-? > > prefixes not routed are effective only in the single broadcast domain > > where they are used. me thinks this "requirement" is overly broad > > and screams for the creation of the "routing police". e.g. > > Geoff and the RIB/FIBettes. eh? > > > > i'm in favor of -NOT- having this language. > > > > --bill > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > > -- > :):) > /S > _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Tue Aug 29 04:23:44 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 29 Aug 2006 09:23:44 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <20060825145647.GA10800@vacation.karoshi.com.> Message-ID: > where is the "global" routing table defined? See below. > is that a universally > agreed on definition? answeringthese questions will help answer > your questions. If nobody objects to the following definition or suggests changes to the wording to make it fit better, then the following is a universally agreed definition of the "global routing table". ---------------- The Global Routing Table refers to the set of all prefixes (address blocks) announced in the default-free zone of the public Internet via BGP4. Theoretically, the routing table in a peering router of any member of the default-free zone will consist of the "Global Routing Table" plus the more detailed local routes which are only found in that member's network. -------------- If anyone can say it better or more accurately, please contribute. --Michael Dillon From Lee.Howard at stanleyassociates.com Tue Aug 29 07:47:54 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 29 Aug 2006 07:47:54 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4030A8208@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Tuesday, August 29, 2006 4:24 AM > To: ppml at arin.net > Subject: Re: [ppml] question on 2006-2 v6 internal microallocation > > ---------------- > The Global Routing Table refers to the set of all > prefixes (address blocks) announced in the default-free > zone of the public Internet via BGP4. Theoretically, > the routing table in a peering router of any member > of the default-free zone will consist of the "Global > Routing Table" plus the more detailed local routes which > are only found in that member's network. > -------------- Pretty good. What's the "default-free zone"? Is it the case that the Global Routing Table as defined above is the same for all members of this zone? Connecting the dots, is it possible that some members of the default-free zone will have and share certain prefixes among themselves? > If anyone can say it better or more accurately, please > contribute. I can't. But I like finer points. Lee > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From Michael.Dillon at btradianz.com Tue Aug 29 08:49:12 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 29 Aug 2006 13:49:12 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4030A8208@CL-S-EX-1.stanleyassociates.com> Message-ID: > > The Global Routing Table refers to the set of all > > prefixes (address blocks) announced in the default-free > > zone of the public Internet via BGP4. Theoretically, > > the routing table in a peering router of any member > > of the default-free zone will consist of the "Global > > Routing Table" plus the more detailed local routes which > > are only found in that member's network. > > -------------- > > Pretty good. > What's the "default-free zone"? The set of BGP4 prefixes announced on the public Internet by network operators who do not make use of a "default route" in their interdomain routing. Some might argue that it is the set of AS numbers of the above operators and that may be a better definition. > Is it the case that the Global Routing Table as defined above > is the same for all members of this zone? Yes. However, the actual routing tables in any given router belonging to any given network operator will not likely reflect the actual full Global Routing Table since most operators use filtering mechanisms. In other words, the Global Routing Table is an abstract concept that could be measured if there was demand to measure it, but which does not necessarily correspond to anything that is currently measured. > Connecting the dots, is it possible that some members of the > default-free zone will have and share certain prefixes among > themselves? I don't understand. The default free zone came about because a set of network operators DO share prefixes (announce prefixes) among themselves as their exclusive means of interdomain connectivity. --Michael Dillon P.S. many of the larger network operators will also operate IP networks and IP internetworks that are not part of the public Internet. They may not be default free in those extra-networks but that is not relevant. The concept of Default-Free Zone only applies to the public Internet. From Lee.Howard at stanleyassociates.com Tue Aug 29 09:55:53 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 29 Aug 2006 09:55:53 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Tuesday, August 29, 2006 8:49 AM > To: ppml at arin.net > Subject: Re: [ppml] question on 2006-2 v6 internal microallocation > > > > The Global Routing Table refers to the set of all > > > prefixes (address blocks) announced in the default-free > > > zone of the public Internet via BGP4. Theoretically, > > > the routing table in a peering router of any member > > > of the default-free zone will consist of the "Global > > > Routing Table" plus the more detailed local routes which > > > are only found in that member's network. > > > -------------- > > > > Pretty good. > > What's the "default-free zone"? > > The set of BGP4 prefixes announced on the public Internet > by network operators who do not make use of a "default route" > in their interdomain routing. > > Some might argue that it is the set of AS numbers of the above > operators and that may be a better definition. > > > Is it the case that the Global Routing Table as defined above > > is the same for all members of this zone? > > Yes. However, the actual routing tables in any given router > belonging to any given network operator will not likely > reflect the actual full Global Routing Table since most > operators use filtering mechanisms. In other words, the > Global Routing Table is an abstract concept that could > be measured if there was demand to measure it, but which > does not necessarily correspond to anything that is currently > measured. I see. The Global Routing Table is not the list of all routes on a given router, but some superset of routing tables among routers in a DFZ AS. Your definition says, "the routing table in a peering router of any member of the default-free zone will consist of the "Global Routing Table" " I took "member" to be "router," since I think of a routing table as a router's routing table. > > Connecting the dots, is it possible that some members of the > > default-free zone will have and share certain prefixes among > > themselves? > > I don't understand. The default free zone came about because > a set of network operators DO share prefixes (announce prefixes) > among themselves as their exclusive means of interdomain > connectivity. Yes. But in our current context, discussing whether there should be a rule or guideline that a prefix not be advertised in the DFZ, if a prefix is advertised between two DFZ ASes, is it in the Global Routing Table? > --Michael Dillon > > P.S. many of the larger network operators will also operate > IP networks and IP internetworks that are not part of the > public Internet. They may not be default free in those > extra-networks but that is not relevant. The concept of > Default-Free Zone only applies to the public Internet. How do you tell the difference? Thank you for using specific language; I think this is very helpful. Lee From info at arin.net Tue Aug 29 10:23:22 2006 From: info at arin.net (Member Services) Date: Tue, 29 Aug 2006 10:23:22 -0400 Subject: [ppml] ARIN XVIII - Open Policy Hour Message-ID: <44F44DDA.3050407@arin.net> SOME QUESTIONS ABOUT THE POLICY PROCESS 1. Do you want to know what policy proposals will be discussed at the upcoming ARIN Public Policy Meeting? 2. Do you want a better understanding about what they are about? 3. Do you want to know what has been said about them so far? 4. Do you have an idea about how ARIN should manage Internet Number Resources? 5. Do you think that a current policy should be enhanced or changed, or even retired? 6. Are you hesitant about making a formal proposal on the Public Policy Mail List (PPML)? 7. Are you new to the Policy Development Process? IF THE ANSWER TO ANY OF THESE QUESTIONS IS YES, THEN YOU SHOULD ATTEND THE OPEN POLICY HOUR! What is THE OPEN POLICY HOUR? Quite simply, it is your opportunity to get a better understanding of what is going to be discussed at the upcoming Public Policy Meeting or for you to discuss your ideas in an open, informal forum and receive feedback or both! The OPEN POLICY HOUR consists of two parts. Part One is the P2B2 or the Policy Proposal Background Briefing. ARIN staff will provide summary information regarding the policy proposals that will be discussed at the meeting. Members of the ARIN Advisory Council will be present to answer general questions about the policy proposals. There will be no discussion of the proposals, just the information that you need to help you understand the nature of the proposals and what has been said so far about them. Part Two is the P2B or the Policy Proposal BOF. This is where you get a chance to "test drive" a policy idea. How can you participate? Bring your ideas and questions. If you have a policy suggestion for which you would like to receive feedback prior to submitting it to the community on the PPML, here is your opportunity. If you have a short (3-minute) presentation prepared you will be given the first opportunity to present it. To sign up to give a presentation please send an e-mail to policy at arin.net by 6 October 2006 with your name, organization, and a brief description of your policy subject. Come join your colleagues in this informal setting. THE OPEN POLICY HOUR for ARIN XVIII will be held on Tuesday, 10 October, from 6:00 - 7:00 PM. Registration for ARIN XVIII is simple. Registration and hotel details are at: http://www.arin.net/ARIN-XVIII/ Contact Member Services at info at arin.net if you have any questions. Regards, Member Services Department American Registry for Internet Numbers From hannigan at renesys.com Tue Aug 29 11:22:24 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Tue, 29 Aug 2006 11:22:24 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanley associates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> Message-ID: <7.0.1.0.2.20060829111630.02385140@renesys.com> At 09:55 AM 8/29/2006, Howard, W. Lee wrote: >Your definition says, "the routing table in a peering >router of any member of the default-free zone will consist >of the "Global Routing Table" " >I took "member" to be "router," since I think of a routing >table as a router's routing table. Here are the members, for the most part, of the DFZ (as compiled today): Level 3 Communications, LLC AS 3356 Sprint AS 1239 UUNET Technologies, Inc. AS 701 Savvis AS 3561 AT&T WorldNet Services AS 7018 NTT America, Inc. AS 2914 Global Crossing AS 3549 Qwest AS 209 TeliaNet Global Network AS 1299 Teleglobe Inc. AS 6453 -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From dlw+arin at tellme.com Tue Aug 29 11:24:07 2006 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 29 Aug 2006 08:24:07 -0700 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> Message-ID: <20060829152407.GJ2989@shell01.corp.tellme.com> On Tue, Aug 29, 2006 at 09:55:53AM -0400, Howard, W. Lee wrote: > > P.S. many of the larger network operators will also operate > > IP networks and IP internetworks that are not part of the > > public Internet. They may not be default free in those > > extra-networks but that is not relevant. The concept of > > Default-Free Zone only applies to the public Internet. > > How do you tell the difference? It doesn't really matter, but we commonly refer to the specific internetwork that has the most routes and greatest content diversity with a capital 'I". The rest of them are just internetworks. I'm connected to a couple of those...the largest one has 8 ASes and perhaps 50 prefixes. It's default-free, but no one would confuse it with the public Internet. Since we seem to use capitalization to discriminate the differences, internetworks like the one I described above are default-free, while the public Internet has a Default-Free Zone. Not a good standard, but people seem to understand this one intuitively. -David, dreaming of faster route convergence for large internetworks From Michael.Dillon at btradianz.com Tue Aug 29 11:26:16 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 29 Aug 2006 16:26:16 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> Message-ID: > I see. The Global Routing Table is not the list of all routes > on a given router, but some superset of routing tables among > routers in a DFZ AS. Not a superset of the routing tables. It is the set of all routes announced into the DFZ regardless of whether they end up in some table or not. The key thing is that a route must be announced to exist. Acceptance of the route is not relevant to its existence. > Your definition says, "the routing table in a peering > router of any member of the default-free zone will consist > of the "Global Routing Table" " > I took "member" to be "router," since I think of a routing > table as a router's routing table. The is a flaw in my statement. I actually said that the router would contain the global routing table plus additional local routes. Of course, the router is likely to contain a subset of the global routing table plus the local routes because the network operator is unlikely to accept 100% of the routes announced in the DFZ. > Yes. But in our current context, discussing whether there should > be a rule or guideline that a prefix not be advertised in the DFZ, > if a prefix is advertised between two DFZ ASes, is it in the Global > Routing Table? There is where a measurement tool helps to clarify things. For instance, I would say that a route announced between two DFZ members by mutual agreement is not part of the global routing table but is an extension of their local routing detail into some form of extranet. But then, does this mean that a route must be announced to 100% of DFZ members to be considered part of the global routing table? Probably not because when MEASURING something like this, 100% will be difficult to achieve. In fact, MEASURING who is and who is not a member of the DFZ will also be difficult. However, if we have an accepted theoretical definition, then we can use that to develop some practical rules of thumb to use in policy (or building measurement tools). > > P.S. many of the larger network operators will also operate > > IP networks and IP internetworks that are not part of the > > public Internet. They may not be default free in those > > extra-networks but that is not relevant. The concept of > > Default-Free Zone only applies to the public Internet. > > How do you tell the difference? I cannot think of any technical means to measure membership in the DFZ that would not require network operators to divulge whether or not they are truly default free. In other words, we can't spy on the network and make this determination. We need the network operators to cooperate in order to access the traffic that would let us determine who is default-free. So, this boils down to a situation in which we have to trust that a network operator is telling the truth when they say that they are default free. This list of default free networks could be honed by removing any network that receives too many complaints from other default free networks saying that the network really is not default free. But this may not be necessary. Since we can't measure the default-free zone or the global routing table exactly, we could still work with an approximation and still make good policy. However, at this point in time there is no accepted ARIN definition of default-free zone or global routing table. So our policy is less of a match to the real world than it could be. ARIN has a tendency to accept slippery-slope arguments and throw the baby out with the bath water. I believe that there are reasonable ways to calculate benchmark values at regular intervals for the size of the global routing table and to apply those benchmarks in ARIN's policy-making. For instance, a PI policy could have different criteria for address allocations which will end up in the global routing table and for those that will not. The criteria for those that will could be based on the benchmark size as calculated by ARIN, for instance that ARIN will not issue more than x PI blocks per quarter to limit the rate of growth of the GRT. This factor x could be recalculated once a year according to some formula. Then, the PI policy would require all PI applicants to either undertake NOT to announce their prefix in such a way that it ends up in the GRT or wait until the end of the quarter when lots are drawn to see who gets their allocation. This kind of thing will likely become more and more important as we get closer to the exhaustion of the IPv4 address space because we might need to apply similar restrictive growth policies to all IPv4 allocations. We may as well start experimenting with this now. --Michael Dillon From hannigan at renesys.com Tue Aug 29 11:27:13 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Tue, 29 Aug 2006 11:27:13 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <7.0.1.0.2.20060829111630.02385140@renesys.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> <7.0.1.0.2.20060829111630.02385140@renesys.com> Message-ID: <7.0.1.0.2.20060829112603.023d2b90@renesys.com> At 11:22 AM 8/29/2006, Martin Hannigan wrote: >At 09:55 AM 8/29/2006, Howard, W. Lee wrote: > > >Your definition says, "the routing table in a peering > >router of any member of the default-free zone will consist > >of the "Global Routing Table" " > >I took "member" to be "router," since I think of a routing > >table as a router's routing table. > >Here are the members, for the most part, of the DFZ >(as compiled today): Oh, pardon the HTML, here it is in text and with the disclaimer again "for the most part". Level3 Sprint Savvis ATT NTT GBLX Qwest Telia Teleglobe VSNL -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From Michael.Dillon at btradianz.com Tue Aug 29 11:29:03 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 29 Aug 2006 16:29:03 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <7.0.1.0.2.20060829111630.02385140@renesys.com> Message-ID: > Here are the members, for the most part, of the DFZ > (as compiled today): Why the ugly URLs that do not work anyway? In any case, this is roughly what I expected the list to be. Can you divulge how you determined this to be the list of DFZ members? Is your method something that can easily be repeated on a quarterly basis? > Level > 3 Communications, LLC AS 3356 > >Sprint AS 1239 > UUNET > Technologies, Inc. AS 701 > Savvis > AS 3561 > AT&T > WorldNet Services AS 7018 > NTT > America, Inc. AS 2914 > Global > Crossing AS 3549 > Qwest AS 209 > TeliaNet > Global Network AS 1299 > Teleglobe > Inc. AS 6453 --Michael Dillon From kloch at hotnic.net Tue Aug 29 12:05:07 2006 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 29 Aug 2006 12:05:07 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <7.0.1.0.2.20060829111630.02385140@renesys.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> <7.0.1.0.2.20060829111630.02385140@renesys.com> Message-ID: <44F465B3.80203@hotnic.net> Martin Hannigan wrote: > Here are the members, for the most part, of the DFZ > (as compiled today): I always interpreted DFZ as "default free", not "transit free". Is this usage common? -Kevin From hannigan at renesys.com Tue Aug 29 12:42:07 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Tue, 29 Aug 2006 12:42:07 -0400 Subject: [ppml] 2006-1 Residential Customer Privacy Update In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A42BB3@nyrofcs2ke2k01.co rp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A01A42BB3@nyrofcs2ke2k01.corp.pvt> Message-ID: <7.0.1.0.2.20060829122151.022aa668@renesys.com> At 12:42 PM 8/22/2006, Azinger, Marla wrote: >This is an update on the status of 2006-1 and also a "nudge" to try >and start discussion again. > Thanks. >On Topic Opinions: > >1. I believe the current Residential Policy is satisfactory and >should be left unchanged. If someone has security risks then the >information in ARIN WHOIS is the least of their problem as to where >sensitive information can be easily accessed on the internet. Yes, I'll go with this position. The ori.author demonstrated that the security risks are almost incalculable and if you ran the remaining problem through a probability model using whois as one of the hundreds of publicly available data sources that identify people and their history available today, whois whould never be chosen as the source. The expectation of homing down a whois manhunt to three people in any given truncated zip code is, well, "funny" statistically. I'd like to thank the AC for asking me my opinion during the process and we remain open to any reasonable and factually based compromise position. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From schiller at uu.net Tue Aug 29 13:25:10 2006 From: schiller at uu.net (Jason Schiller) Date: Tue, 29 Aug 2006 13:25:10 -0400 (EDT) Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: Message-ID: On Tue, 29 Aug 2006 Michael.Dillon at btradianz.com wrote: > In any case, this is roughly what I expected the > list to be. Can you divulge how you determined this > to be the list of DFZ members? Is your method something > that can easily be repeated on a quarterly basis? Or as it relates to policy, is there a way one could describe a set of conditions that would determine if an AS is or is not in the DFZ? ___Jason From schiller at uu.net Tue Aug 29 17:00:03 2006 From: schiller at uu.net (Jason Schiller) Date: Tue, 29 Aug 2006 17:00:03 -0400 (EDT) Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <7.0.1.0.2.20060829112603.023d2b90@renesys.com> Message-ID: Martin, Your original email in html had AS701 UUNET on the list. The text version didn't. Not sure if that actually makes a big deal either way wrt the arin policy on micro-allocations for internal infrastructure. ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Tue, 29 Aug 2006, Martin Hannigan wrote: > Date: Tue, 29 Aug 2006 11:27:13 -0400 > From: Martin Hannigan > To: "Howard, W. Lee" , ppml at arin.net > Subject: Re: [ppml] question on 2006-2 v6 internal microallocation > > At 11:22 AM 8/29/2006, Martin Hannigan wrote: > >At 09:55 AM 8/29/2006, Howard, W. Lee wrote: > > > > >Your definition says, "the routing table in a peering > > >router of any member of the default-free zone will consist > > >of the "Global Routing Table" " > > >I took "member" to be "router," since I think of a routing > > >table as a router's routing table. > > > >Here are the members, for the most part, of the DFZ > >(as compiled today): > > > Oh, pardon the HTML, here it is in text and with the > disclaimer again "for the most part". > > > Level3 > Sprint > Savvis > ATT > NTT > GBLX > Qwest > Telia > Teleglobe VSNL > > > > > > > -- > Martin Hannigan (c) 617-388-2663 > Renesys Corporation (w) 617-395-8574 > Member of Technical Staff Network Operations > hannigan at renesys.com > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From hannigan at renesys.com Tue Aug 29 18:10:13 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Tue, 29 Aug 2006 18:10:13 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <44F465B3.80203@hotnic.net> References: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> <7.0.1.0.2.20060829111630.02385140@renesys.com> <44F465B3.80203@hotnic.net> Message-ID: <7.0.1.0.2.20060829180959.02335920@renesys.com> At 12:05 PM 8/29/2006, Kevin Loch wrote: >Martin Hannigan wrote: > > Here are the members, for the most part, of the DFZ > > (as compiled today): > >I always interpreted DFZ as "default free", not "transit free". >Is this usage common? transit-free. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From hannigan at renesys.com Tue Aug 29 18:11:42 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Tue, 29 Aug 2006 18:11:42 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: References: <7.0.1.0.2.20060829112603.023d2b90@renesys.com> Message-ID: <7.0.1.0.2.20060829181053.02331588@renesys.com> At 05:00 PM 8/29/2006, Jason Schiller wrote: >Martin, > >Your original email in html had AS701 UUNET on the list. The text version >didn't. Not sure if that actually makes a big deal either way wrt the >arin policy on micro-allocations for internal infrastructure. > >___Jason Jason - the cut and paste widget grabbed the HTML instead of just the text so in transcribing, you were dropped accidentally. Verizon Business is ON that list. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From ppml at rs.seastrom.com Tue Aug 29 18:18:59 2006 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Tue, 29 Aug 2006 18:18:59 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <44F465B3.80203@hotnic.net> (Kevin Loch's message of "Tue, 29 Aug 2006 12:05:07 -0400") References: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> <7.0.1.0.2.20060829111630.02385140@renesys.com> <44F465B3.80203@hotnic.net> Message-ID: <87hczvxk18.fsf@valhalla.seastrom.com> Kevin Loch writes: > Martin Hannigan wrote: >> Here are the members, for the most part, of the DFZ >> (as compiled today): > > I always interpreted DFZ as "default free", not "transit free". > Is this usage common? If you have an ASN and you take routes from one or more upstreams &/or peers and therefore you do not have a default route in your network then you are part of the DFZ. Bringing up whether or not people pay for transit or peer all their traffic off to other big players or mooch free transit from their friends' companies simply clouds the issue. The DFZ contains everyone who gets indigestion from internet routing table growth... from basement multihomers to major universities to large enterprises to multinational ISPs. ---Rob From ras at e-gerbil.net Tue Aug 29 18:19:09 2006 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 29 Aug 2006 18:19:09 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <7.0.1.0.2.20060829180959.02335920@renesys.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> <7.0.1.0.2.20060829111630.02385140@renesys.com> <44F465B3.80203@hotnic.net> <7.0.1.0.2.20060829180959.02335920@renesys.com> Message-ID: <20060829221909.GF29484@overlord.e-gerbil.net> On Tue, Aug 29, 2006 at 06:10:13PM -0400, Martin Hannigan wrote: > At 12:05 PM 8/29/2006, Kevin Loch wrote: > >Martin Hannigan wrote: > > > Here are the members, for the most part, of the DFZ > > > (as compiled today): > > > >I always interpreted DFZ as "default free", not "transit free". > >Is this usage common? > > transit-free. Default-free means quite simply, you don't have a default route, aka you carry a complete view of the global Internet routing table to make your routing decisions. Really it has nothing to do with being transit-free, nor does being transit-free have anything to do with whether a route is announced in the global table. At any rate, FYI in the previous list Teleglobe is not transit-free (which, btw is not the same thing as SETTLEMENT free :P), they receive a full transit feed from 1239 as verifiable through their looking glass. If you really care, you can start by looking at the Wikipedia article on "Tier 1 network" (which *gasp* is actually correct at the moment :P) for a verified list of settlement and transit free networks (aka Tier 1's :P), but again, this has nothing to do with anything. Personally I think if you can't just say "Global Internet Routing Table" and have a complete and air-tight understanding of what is being referenced, we've got bigger problems. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From hannigan at renesys.com Tue Aug 29 18:27:44 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Tue, 29 Aug 2006 18:27:44 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <20060829221909.GF29484@overlord.e-gerbil.net> References: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> <7.0.1.0.2.20060829111630.02385140@renesys.com> <44F465B3.80203@hotnic.net> <7.0.1.0.2.20060829180959.02335920@renesys.com> <20060829221909.GF29484@overlord.e-gerbil.net> Message-ID: <7.0.1.0.2.20060829182058.02355ec0@renesys.com> At 06:19 PM 8/29/2006, Richard A Steenbergen wrote: >On Tue, Aug 29, 2006 at 06:10:13PM -0400, Martin Hannigan wrote: > > At 12:05 PM 8/29/2006, Kevin Loch wrote: > > >Martin Hannigan wrote: > > > > Here are the members, for the most part, of the DFZ > > > > (as compiled today): > > > > > >I always interpreted DFZ as "default free", not "transit free". > > >Is this usage common? > > > > transit-free. > >Default-free means quite simply, you don't have a default route, aka you >carry a complete view of the global Internet routing table to make your >routing decisions. Really it has nothing to do with being transit-free, >nor does being transit-free have anything to do with whether a route is >announced in the global table. At any rate, FYI in the previous list >Teleglobe is not transit-free (which, btw is not the same thing as >SETTLEMENT free :P), they receive a full transit feed from 1239 as >verifiable through their looking glass. If you really care, you can start >by looking at the Wikipedia article on "Tier 1 network" (which *gasp* is >actually correct at the moment :P) for a verified list of settlement and >transit free networks (aka Tier 1's :P), but again, this has nothing to do >with anything. Let's be clear on a few things. Yes, I don't disagree on DFZ. There's a bit if dyslexia in there. The second is that we aren't claiming anyone is settlement free, but as you can imagine from a our ranking, going from 1 to Nth is settlement free. They are publicly available here: http://www.renesys.com/products_services/market_intel/rankings/ >Personally I think if you can't just say "Global Internet Routing Table" >and have a complete and air-tight understanding of what is being >referenced, we've got bigger problems. :) I agree. Posting for the sake of posting is one of them. :) -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From ras at e-gerbil.net Tue Aug 29 18:43:57 2006 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 29 Aug 2006 18:43:57 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <7.0.1.0.2.20060829182058.02355ec0@renesys.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> <7.0.1.0.2.20060829111630.02385140@renesys.com> <44F465B3.80203@hotnic.net> <7.0.1.0.2.20060829180959.02335920@renesys.com> <20060829221909.GF29484@overlord.e-gerbil.net> <7.0.1.0.2.20060829182058.02355ec0@renesys.com> Message-ID: <20060829224356.GG29484@overlord.e-gerbil.net> On Tue, Aug 29, 2006 at 06:27:44PM -0400, Martin Hannigan wrote: > > Let's be clear on a few things. Yes, I don't disagree on DFZ. There's > a bit if dyslexia in there. The second is that we aren't claiming anyone > is settlement free, but as you can imagine from a our ranking, going > from 1 to Nth is settlement free. > > They are publicly available here: > > http://www.renesys.com/products_services/market_intel/rankings/ Well, on the subject of posting irrelevent things for the sake of posting, what does "size of customer base" have to do with default free, settlement free, or transit free? There are some folks with much smaller networks who legitiately ARE transit free (through paid peering with everyone) who aren't anywhere near that list, and there are other folks with much larger networks who do pay for and receive full transit feeds who worked their way in right after the Tier 1's (which stop at #8). Not saying that this isn't interesting data, but it has absolutely no relevence to the "* free" discussions. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From hannigan at renesys.com Tue Aug 29 19:28:33 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Tue, 29 Aug 2006 19:28:33 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <87hczvxk18.fsf@valhalla.seastrom.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4030A82AC@CL-S-EX-1.stanleyassociates.com> <7.0.1.0.2.20060829111630.02385140@renesys.com> <44F465B3.80203@hotnic.net> <87hczvxk18.fsf@valhalla.seastrom.com> Message-ID: <7.0.1.0.2.20060829184413.023d66f0@renesys.com> At 06:18 PM 8/29/2006, Robert E.Seastrom wrote: >Kevin Loch writes: > > > Martin Hannigan wrote: > >> Here are the members, for the most part, of the DFZ > >> (as compiled today): > > > > I always interpreted DFZ as "default free", not "transit free". > > Is this usage common? > >If you have an ASN and you take routes from one or more upstreams &/or peers >and >therefore you do not have a default route in your network >then >you are part of the DFZ. > >Bringing up whether or not people pay for transit or peer all their >traffic off to other big players or mooch free transit from their >friends' companies simply clouds the issue. The DFZ contains everyone >who gets indigestion from internet routing table growth... from >basement multihomers to major universities to large enterprises to >multinational ISPs. > > ---Rob I've already admitted dyslexia, and I may have some acid indigestion to confess to as well now. The posting of the ranking was supposed to be neutral and I apologize for the URL's. I'm on a windows box and .... :) Posting the ranking was specifically targeted at: "Your definition says, "the routing table in a peering >router of any member of the default-free zone will consist >of the "Global Routing Table" " >I took "member" to be "router," since I think of a routing >table as a router's routing table. ... which I intepreted to mean a network of the authors caliber - which are likely to be settlement and default free in the situation as described. It is important to have an understanding of the economical practices of these networks, although I'm not sure if this is on topic. I'd be happy to elaborate on this over a taco and a coke. :) Thanks for helping to be clear on the DFZ definition. I appreciate that. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From Michael.Dillon at btradianz.com Wed Aug 30 06:00:27 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 30 Aug 2006 11:00:27 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <20060829221909.GF29484@overlord.e-gerbil.net> Message-ID: > Personally I think if you can't just say "Global Internet Routing Table" > and have a complete and air-tight understanding of what is being > referenced, we've got bigger problems. :) It's called "ambiguous language". A routing table is normally something that you find inside routing software. But the Global Internet Routing Table is not inside routing software. Therefore the term is ambiguous. Of course the insiders and elite of the industry have no problem understanding what is what, however, ARIN was created for the express purpose of taking address policymaking out of the hands of the elite insiders and into the hands of the public (at least those concerned about addresses). For the purposes of open policymaking and to achieve ARIN's purposes in education, it is important to have clear definitions and not simply rely on what everybody thinks that everybody else knows. --Michael Dillon From Michael.Dillon at btradianz.com Wed Aug 30 06:04:49 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 30 Aug 2006 11:04:49 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <20060829224356.GG29484@overlord.e-gerbil.net> Message-ID: > Not saying that this > isn't interesting data, but it has absolutely no relevence to the "* free" > discussions. It is also data from a consultancy firm who presumably has competitors with their own sources and their own data which may be more accurate in some cases. It all comes down to goals and definitions. The goals of a commercial consultancy are different from ARIN's goals and definitions which are workable for a consultancy may not be workable at all for ARIN. --Michael Dillon From Michael.Dillon at btradianz.com Wed Aug 30 06:08:37 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 30 Aug 2006 11:08:37 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: Message-ID: > Or as it relates to policy, is there a way one could describe a set of > conditions that would determine if an AS is or is not in the DFZ? I think that is what we will have to develop since I don't think we will be able to accurately measure the DFZ. It might be simply a set of conditions or it might be some mechanism as well based on the fact that an applicant will normally provide info to ARIN under NDA, therefore they could open themselves to some sort of probing to test DFZ-ness. --Michael Dillon From info at arin.net Wed Aug 30 19:22:07 2006 From: info at arin.net (Member Services) Date: Wed, 30 Aug 2006 19:22:07 -0400 Subject: [ppml] NRPM version 2006.2 - New Policy Implementations Message-ID: <003601c6cc8b$1c3a6fb0$5f8888c0@arin.net> On 9 May 2006, the ARIN Board of Trustees, based on the recommendation of the Advisory Council and noting that the Internet Resource Policy Evaluation Process had been followed, adopted the following policy proposals: 2005-1: Provider-independent IPv6 Assignments for End Sites 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement 2005-9: 4-Byte AS Number These policy proposals have been incorporated into version 2006.2 of the ARIN Number Resource Policy Manual (NRPM) which is effective 30 August 2006. NRPM version 2006.2 supersedes previous versions. See Appendix A of the NRPM for information regarding changes to the manual. The NRPM can be found at: http://www.arin.net/policy/nrpm.html Appendix A can be found at: http://www.arin.net/policy/nrpm_changelog.html On 11 July 2006, the ARIN Board of Trustees added IPv6 Assignments to the ARIN fee schedule. The Board waived all but $500 of the IPv6 Initial Assignment fee through 31 December 2007. The fee schedule can be found at: http://www.arin.net/billing/fee_schedule.html For information about requesting an IPv6 assignment, please see the guidelines at: http://www.arin.net/registration/guidelines/ipv6_assignment.html Regards, Member Services American Registry for Internet Numbers (ARIN) From bmanning at vacation.karoshi.com Thu Aug 31 09:40:45 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 31 Aug 2006 13:40:45 +0000 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: References: <20060825145647.GA10800@vacation.karoshi.com.> Message-ID: <20060831134045.GB23809@vacation.karoshi.com.> On Tue, Aug 29, 2006 at 09:23:44AM +0100, Michael.Dillon at btradianz.com wrote: > > where is the "global" routing table defined? > > See below. > > > is that a universally > > agreed on definition? answeringthese questions will help answer > > your questions. > > If nobody objects to the following definition or suggests > changes to the wording to make it fit better, then the > following is a universally agreed definition of the > "global routing table". > > ---------------- > The Global Routing Table refers to the set of all > prefixes (address blocks) announced in the default-free > zone of the public Internet via BGP4. Theoretically, > the routing table in a peering router of any member > of the default-free zone will consist of the "Global > Routing Table" plus the more detailed local routes which > are only found in that member's network. > -------------- > > If anyone can say it better or more accurately, please > contribute. its self referential... default-free means no default route. there is zero implication wrt "global" in a default-free network. --bill > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Thu Aug 31 11:11:35 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 31 Aug 2006 16:11:35 +0100 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: <20060831134045.GB23809@vacation.karoshi.com.> Message-ID: > > The Global Routing Table refers to the set of all > > prefixes (address blocks) announced in the default-free > > zone of the public Internet via BGP4. Theoretically, > > the routing table in a peering router of any member > > of the default-free zone will consist of the "Global > > Routing Table" plus the more detailed local routes which > > are only found in that member's network. > its self referential... default-free means no default > route. But the term being defined is "global routing table" so referring to "default-free zone" is not self-referential. The "global routing table" is a list of prefixes that are being announced. This is why people refer to using up "slots" in the global routing table. On the other hand the "default-free zone" is more like a list of AS numbers. There appears to be no near-term limit to the size of the default-free zone other than the 32-bits in an AS number. >there is zero implication wrt "global" in a default-free > network. Not sure that I understand this. A default-free network is not necessarily spread out over all parts of the globe. But it does participate in the "default-free zone" which is a global concept. And it does consume one or more slots in the "global routing table". Some NANOG folks have created a NANOG Wiki to expand on the existing NANOG FAQ. I have taken advantage of this by creating two new entries, http://nanog.cluepon.net/index.php/Default-Free_Zone http://nanog.cluepon.net/index.php/Global_Routing_Table Since anyone else can join and edit the content of the wiki, please feel free to adjust the wording of the definitions that I have posted there. Please note, I didn't just copy what I write in one of my emails. I don't claim to have the perfect definitions yet. But perhaps a WIKI is a better way for several people to work towards an agreed text. --Michael Dillon From hannigan at renesys.com Thu Aug 31 16:41:17 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Thu, 31 Aug 2006 16:41:17 -0400 Subject: [ppml] question on 2006-2 v6 internal microallocation In-Reply-To: References: <20060831134045.GB23809@vacation.karoshi.com.> Message-ID: <7.0.1.0.2.20060831163855.00f50d58@renesys.com> At 11:11 AM 8/31/2006, Michael.Dillon at btradianz.com wrote: >Some NANOG folks have created a NANOG Wiki to expand on the >existing NANOG FAQ. I have taken advantage of this by creating >two new entries, >http://nanog.cluepon.net/index.php/Default-Free_Zone >http://nanog.cluepon.net/index.php/Global_Routing_Table >Since anyone else can join and edit the content of the wiki, >please feel free to adjust the wording of the definitions >that I have posted there. > >Please note, I didn't just copy what I write in one >of my emails. I don't claim to have the perfect >definitions yet. But perhaps a WIKI is a better way >for several people to work towards an agreed text. > I'm sorry, but I can't not mention that you wrote those Wiki references and none of us have had a chance to have input on them. Why don't we take this discussion to NANOG? It's operational and the building, and pending, flameage is generally more on topic? -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com