From jlewis at lewis.org Wed Nov 1 16:57:05 2006 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 1 Nov 2006 16:57:05 -0500 (EST) Subject: [ppml] past due annual renewal policy Message-ID: Section 4.2.1.2 (Annual Renewal) of the ARIN Number Resource Policy Manual mentions that: If not paid by the anniversary date, the address space may be revoked. Is there an actual policy as to the number of years or a dollar figure a member can get behind paying their annual fees before ARIN attempts to revoke IP/ASN resources? I've been contacted by a network that is behind (how far, I don't know) and has just been given rather short notice that their PI IP space is about to be revoked. I wasn't aware of this ever having happened before, so I wonder if there are any precedents or policies on the matter? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From marla.azinger at frontiercorp.com Thu Nov 2 15:42:35 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 2 Nov 2006 15:42:35 -0500 Subject: [ppml] Multihome Pro Con Followup Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D04115@nyrofcs2ke2k01.corp.pvt> Hello- It has been a little over 2 weeks since I posted the Multihoming with IPv6 Pro Con Document. I hope this has been enough time for people to review it and see for themselves just how difficult finding a good solutioin will be for all of us. I know that once this document is read it becomes clear that not one solution in the forefront is a perfect solution. Since the posting 2 weeks ago I have received emails from several different individuals that are already thinking outside of the box and looking towards working on turning some of the imperfect suggested solutions and turning them into good solutions. It is great that our Internet community can read a pro con document and realize that the best solution may not be right before our eyes but only several grueling but hard fought brain storms and work sessions away. I want to thank everyone out there that is spending time on this subject and I will do my best to keep this document updated with the new possible solutions that are sure to arise. Thank you for your time Marla Azinger ARIN AC Frontier Communications From marla.azinger at frontiercorp.com Mon Nov 13 13:59:58 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 13 Nov 2006 13:59:58 -0500 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- Input Requested Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DCF5@nyrofcs2ke2k01.corp.pvt> Hello- In an effort to work with the community on changes to Policy Proposal 2006-7 Changes to IPV6 Initial Allocation Criteria, three different suggested revisions are in this email. We would like the communities input on three separate suggested revisions. What do you like about them, or what do you not like about them? Do you prefer one suggestion over the other? I have given each suggestion a different color to make it easier to tell when one suggestion ands and another begins. When reviewing the three suggested changes please note the following assumptions: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. -Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. - Organization in this is defined as a Corporation, ISP, LLC et al. Suggested Change #1 (deletes and replaces current text of item d and requires ASN) Replace line item d. to 6.5.1.1 with the following: 'To qualify for an initial allocation of IPV6 address space, an organization must': d. be an existing, known ISP in the ARIN region OR be an organization which can justify intent to announce the requested IPv6 address space within one year and have/obtain and AS Number. Rationale for ASN: Someone providing this kind of service needs to run BGP. Suggested Change #2 (deletes and replaces current text of item d but does not require ASN) Replace line item d. to 6.5.1.1 with the following: 'To qualify for an initial allocation of IPv6 address space, an organization must': d. be an existing, known ISP in the ARIN region OR be an organization which can justify intent to announce the requested IPv6 address space within one year. Rationale for no asn: We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. Suggested Change #3 (leaves item d in place with the 200 /48 text and adds a new item e but does not require ASN) Insert line item e. to 6.5.1.1 with the following: 'To qualify for an initial allocation of IPV6 address space, an organization must': e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Rationale for no asn: We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. Thank you for your time Marla (ARIN AC) and Jordi (Proposal Author) From aaronh at bind.com Mon Nov 13 15:53:39 2006 From: aaronh at bind.com (Aaron Hughes) Date: Mon, 13 Nov 2006 12:53:39 -0800 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- Input Requested In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DCF5@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A01A3DCF5@nyrofcs2ke2k01.corp.pvt> Message-ID: <20061113205339.GI26483@user1.bind.com> I would vote for suggested change 1 and not worry so much about ASN bloat with 4 byte ASN addressing that issue. It still does not 'require' BGP but does require having an ASN and allows for ISPs/LIRs/ORGs to announce as needed. Also, since there is no requirement to have space be 'globally available' an announcement in this case could in fact be private which leaves flexibility for those who need it. Cheers, Aaron On Mon, Nov 13, 2006 at 01:59:58PM -0500, Azinger, Marla wrote: > Hello- In an effort to work with the community on changes to Policy Proposal 2006-7 Changes to IPV6 Initial Allocation Criteria, three different suggested revisions are in this email. We would like the communities input on three separate suggested revisions. What do you like about them, or what do you not like about them? Do you prefer one suggestion over the other? I have given each suggestion a different color to make it easier to tell when one suggestion ands and another begins. When reviewing the three suggested changes please note the following assumptions: > > - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. > - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. > -Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. > - Organization in this is defined as a Corporation, ISP, LLC et al. > > > Suggested Change #1 (deletes and replaces current text of item d and requires ASN) > Replace line item d. to 6.5.1.1 with the following: > 'To qualify for an initial allocation of IPV6 address space, an organization must': > d. be an existing, known ISP in the ARIN region OR be an organization which > can justify intent to announce the requested IPv6 address space within one > year and have/obtain and AS Number. > > Rationale for ASN: > Someone providing this kind of service needs to run BGP. > > > Suggested Change #2 (deletes and replaces current text of item d but does not require ASN) > Replace line item d. to 6.5.1.1 with the following: > 'To qualify for an initial allocation of IPv6 address space, an organization > must': > d. be an existing, known ISP in the ARIN region OR be an organization which > can justify intent to announce the requested IPv6 address space within one > year. > > Rationale for no asn: > We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. > > > Suggested Change #3 (leaves item d in place with the 200 /48 text and adds a new item e but does not require ASN) > Insert line item e. to 6.5.1.1 with the following: > 'To qualify for an initial allocation of IPV6 address space, an organization must': > e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. > > Rationale for no asn: > We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. > > Thank you for your time > Marla (ARIN AC) and Jordi (Proposal Author) > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From owen at delong.com Mon Nov 13 16:10:09 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Nov 2006 13:10:09 -0800 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- Input Requested In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01D0414E@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A01D0414E@nyrofcs2ke2k01.corp.pvt> Message-ID: <50AEFAA1-6947-4CAD-8C94-BF5DD57FAC65@delong.com> Sorry... Thought I had. Owen On Nov 13, 2006, at 12:57 PM, Azinger, Marla wrote: > Hi Owen- Thank you for your input. Would you mind sending your > response to the ppml and not just me? > > Thank you > Marla > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, November 13, 2006 12:52 PM > To: Azinger, Marla > Subject: Re: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- > Input Requested > > > My preference is for #3. I think it provides the greatest > flexibility in meeting the widest > range of organization's needs while still preserving reasonable > process and requirements. > > > Owen > >> Suggested Change #3 (leaves item d in place with the 200 /48 text >> and adds a new item e but does not require ASN) >> Insert line item e. to 6.5.1.1 with the following: >> 'To qualify for an initial allocation of IPV6 address space, an >> organization must': >> e. OR be an organization new to providing internet services, and >> can justify intent to announce the requested IPV6 address space >> within one year, through records such as contracts, inventory and/ >> or other applicable documentation. > From michel at arneill-py.sacramento.ca.us Mon Nov 13 23:06:09 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 13 Nov 2006 20:06:09 -0800 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- InputRequested In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DCF5@nyrofcs2ke2k01.corp.pvt> Message-ID: > Azinger, Marla wrote: > Rationale for no asn: > We should not require an ASN if they really don't need one? > As long as they are statically routed to an upstream and don't > want to run bgp/announce directly to the Internet, they don't > need an ASN, therefore we shouldn't create policy that would > contribute to ASN bloat. There is no such thing as an ASN bloat. Note that I'm not saying we should go to Change #1, but the argument about ASN bloat does not hold water with 32-bit AS Numbers: Even if each AS announces only 1 prefix, we have a problem with routing table bloat a long time before we get to 4 billion ASNs. When we get to 1 billion ASNs and 1+ billion entries in the GRT :-D then we can think about ASN bloat and how to stop it before the 4 billion limit hits us. Michel. From Michael.Dillon at btradianz.com Tue Nov 14 05:41:12 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 14 Nov 2006 10:41:12 +0000 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- Input Requested In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DCF5@nyrofcs2ke2k01.corp.pvt> Message-ID: > d. be an existing, known ISP in the ARIN region OR be an organization which > can justify intent to announce the requested IPv6 address space within one > year. This is the best of the lot. No need for an ASN since ISP startups have never needed an ASN to get IPv4 allocations. No need for language about contracts and documents since this already is part of the IPv4 inital allocation process. But, I also think that it is unneccessary to mention announcements since ISP startups have not had that requirement with IPv4. Not all network architectures require address ranges to be announced in BGP4 and not all BGP4 announcements are visible to the so-called public Internet. To put it simply, if an organization can show some justification that they are operating or about to operate an IPv6 network which supplies connectivity services to the networks (IPv6 or not) of other organizations, then this should be enough to give them an IPv6 ISP allocation. The whole reason for the distinction between allocation and assignment in IPv4 was that ISP networks connect other networks and therefore are constantly growing at a rate faster than end-user networks. We have to be careful that we are not just tinkering with language here or we will create more problems. The meaning and intent behind the language are what is important. --Michael Dillon From BillD at cait.wustl.edu Tue Nov 14 09:09:47 2006 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 14 Nov 2006 08:09:47 -0600 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes-Input Requested In-Reply-To: Message-ID: I largely agree with Michael on this. If ARIN assesses that an application for v6 address space is legitimate and timely (within a year), then I believe an allocation can be made. Part of that assessment may constitute need for ASNs, etc. depending upon the business plan and architectural model presented. Bill Darte Washington University in St. Louis > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Tuesday, November 14, 2006 4:41 AM > To: ppml at arin.net > Subject: Re: [ppml] 2006-7 IPV6 Initial Allocation suggested > changes-Input Requested > > > > d. be an existing, known ISP in the ARIN region OR be an > organization > which > > can justify intent to announce the requested IPv6 address > space within > one > > year. > > This is the best of the lot. No need for an ASN since > ISP startups have never needed an ASN to get IPv4 > allocations. No need for language about contracts and > documents since this already is part of the IPv4 inital > allocation process. > > But, I also think that it is unneccessary to mention > announcements since ISP startups have not had that > requirement with IPv4. Not all network architectures require > address ranges to be > announced in BGP4 and not all BGP4 announcements are visible > to the so-called public Internet. > > To put it simply, if an organization can show some > justification that they are operating or about to operate an > IPv6 network which supplies connectivity services to the > networks (IPv6 or not) of other organizations, then this > should be enough to give them an IPv6 ISP allocation. The > whole reason for the distinction between allocation and > assignment in IPv4 was that ISP networks connect > other networks and therefore are constantly growing at a rate > faster than end-user networks. > > We have to be careful that we are not just tinkering with > language here or we will create more problems. The meaning > and intent behind the language are what is important. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From marla.azinger at frontiercorp.com Tue Nov 14 11:30:37 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Tue, 14 Nov 2006 11:30:37 -0500 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- InputRequested Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DCF7@nyrofcs2ke2k01.corp.pvt> Bloat may be a bad word to use. How about 'waste'? That is more to the point. ASN's that show up in routing for only one connection can be argued as 'waste'. ASN's that are requested but not used just to they could get IPV6 space would be a 'waste'. For the sake of not arguing over the use of a word, 'waste' would be more appropriate and bloat should probably be dropped. -----Original Message----- From: Michel Py [mailto:michel at arneill-py.sacramento.ca.us] Sent: Monday, November 13, 2006 8:06 PM To: Azinger, Marla; ppml at arin.net Subject: RE: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- InputRequested > Azinger, Marla wrote: > Rationale for no asn: > We should not require an ASN if they really don't need one? > As long as they are statically routed to an upstream and don't > want to run bgp/announce directly to the Internet, they don't > need an ASN, therefore we shouldn't create policy that would > contribute to ASN bloat. There is no such thing as an ASN bloat. Note that I'm not saying we should go to Change #1, but the argument about ASN bloat does not hold water with 32-bit AS Numbers: Even if each AS announces only 1 prefix, we have a problem with routing table bloat a long time before we get to 4 billion ASNs. When we get to 1 billion ASNs and 1+ billion entries in the GRT :-D then we can think about ASN bloat and how to stop it before the 4 billion limit hits us. Michel. From Michael.Dillon at btradianz.com Tue Nov 14 11:58:45 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 14 Nov 2006 16:58:45 +0000 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- InputRequested In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DCF7@nyrofcs2ke2k01.corp.pvt> Message-ID: > Bloat may be a bad word to use. How about 'waste'? That is more to > the point. ASN's that show up in routing for only one connection > can be argued as 'waste'. Not at all!!! ASNs are REQUIRED when a network is operated by an autonomous organization regardless of whether or not they show up in "routing" anywhere. The rough rule of thumb that determines when an organization is autonomous is when they connect to more than one network that has already been accepted as an autonomous network. Beyond that, we don't need any more definitions, especially not definitions of "waste" that represent only one technical point of view. The Internet numbering resources that we are stewarding, are the joint property of the entire community of people who use the Internet protocol (IP). Therefore, our policies have to find a middle ground in the interests of all these parties. That's what stewardship is, i.e. managing resources on behalf of a community containing different points of view. > ASN's that are requested but not used > just to they could get IPV6 space would be a 'waste'. For the sake > of not arguing over the use of a word, 'waste' would be more > appropriate and bloat should probably be dropped. The word "waste" is not appropriate in any policy dealing with IPv6 resources. It is appropriate in policies dealing with IPv4 resources but only until we know what happens as we approach the event horizon. It is entirely possible that IPv4 demand will drop and IPv4 address space will be returned in sufficient amounts for us to not consider waste any more in IPv4 policies. --Michael Dillon From marla.azinger at frontiercorp.com Tue Nov 14 12:29:18 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Tue, 14 Nov 2006 12:29:18 -0500 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggestedchanges- InputRequested Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D04153@nyrofcs2ke2k01.corp.pvt> LOL, ok. I'm going to leave it alone and just let people chime in with their thoughts and opinions. The last thing I want to start is a word and its defintion debate. All that would really do is distract from the intent and progress of this proposal. Thanks for the input Michael. Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Michael.Dillon at btradianz.com Sent: Tuesday, November 14, 2006 8:59 AM To: ppml at arin.net Subject: Re: [ppml] 2006-7 IPV6 Initial Allocation suggestedchanges- InputRequested > Bloat may be a bad word to use. How about 'waste'? That is more to > the point. ASN's that show up in routing for only one connection > can be argued as 'waste'. Not at all!!! ASNs are REQUIRED when a network is operated by an autonomous organization regardless of whether or not they show up in "routing" anywhere. The rough rule of thumb that determines when an organization is autonomous is when they connect to more than one network that has already been accepted as an autonomous network. Beyond that, we don't need any more definitions, especially not definitions of "waste" that represent only one technical point of view. The Internet numbering resources that we are stewarding, are the joint property of the entire community of people who use the Internet protocol (IP). Therefore, our policies have to find a middle ground in the interests of all these parties. That's what stewardship is, i.e. managing resources on behalf of a community containing different points of view. > ASN's that are requested but not used > just to they could get IPV6 space would be a 'waste'. For the sake > of not arguing over the use of a word, 'waste' would be more > appropriate and bloat should probably be dropped. The word "waste" is not appropriate in any policy dealing with IPv6 resources. It is appropriate in policies dealing with IPv4 resources but only until we know what happens as we approach the event horizon. It is entirely possible that IPv4 demand will drop and IPv4 address space will be returned in sufficient amounts for us to not consider waste any more in IPv4 policies. --Michael Dillon _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From gih at apnic.net Tue Nov 14 12:30:54 2006 From: gih at apnic.net (Geoff Huston) Date: Wed, 15 Nov 2006 04:30:54 +1100 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- InputRequested In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DCF7@nyrofcs2ke2k01.co rp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A01A3DCF7@nyrofcs2ke2k01.corp.pvt> Message-ID: <7.0.0.16.2.20061115041446.02d54a20@apnic.net> But just because these numbers don't show up in your routing table does not mean that they don't show up in all routing tables. If I were to peer locally with another ISP here in Australia, then its not likely that this additional peering would appear in any routing table outside of this particular continent. So, from your perspective it would appear that my AS number is singly homed and it looks like "bloat" or "waste" to you, while to me it is necessary to undertake my chosen form of interconnection. So my AS, if it appears to you as a single homed AS, is in fact a "single transit homed" AS from your perspective, but that says nothing about any richer form of local interconnection that is not directly related to transit services. * end of substantive comment - ramblings follow - hit delete now! ** and if you read it anyway and want to post a followup then please keep the followup off the ppml mailing list, as its not really relevant to that list - just send to me directly! Wandering further into this area of the role of ASNs for routing , just for a second, the semantics of an ASN has changed over time - As I understand it, the original model of some decades ago equated an AS to both an interior routing domain and the coupling of this domain to an origination of a collection of prefixes that shared the same routing policy. Over the years the "shared the same routing policy" has disappeared, and now the prefix is the element of routing policy, while the AS is, in effect, the labelling of an interior routing domain. If we ever want to use these tokens for more than what they are today (today, strictly speaking, ASNs form the BGP path metric of last resort and the protocol's loop detector, and their use in the area of routing policy expression is an adornment of the original semantic intent rather than a core feature) and, specifically if we want to use ASNs as forwarding tokens, then, yes the ASN distribution policies would need to accommodate the aspect of one routing domain wanting to express multiple external routing policies using, in such a case, multiple AS numbers. (was that really one sentence? I think less coffee is called for! :-)) Its not bloat, nor is it waste. Its just numbers with meanings! Geoff At 03:30 AM 15/11/2006, Azinger, Marla wrote: >Bloat may be a bad word to use. How about 'waste'? From marla.azinger at frontiercorp.com Tue Nov 14 13:01:27 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Tue, 14 Nov 2006 13:01:27 -0500 Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- InputRequested Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D04155@nyrofcs2ke2k01.corp.pvt> Thank you Geoff. Good points! Marla -----Original Message----- From: Geoff Huston [mailto:gih at apnic.net] Sent: Tuesday, November 14, 2006 9:31 AM To: Azinger, Marla; ppml at arin.net Subject: Re: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- InputRequested But just because these numbers don't show up in your routing table does not mean that they don't show up in all routing tables. If I were to peer locally with another ISP here in Australia, then its not likely that this additional peering would appear in any routing table outside of this particular continent. So, from your perspective it would appear that my AS number is singly homed and it looks like "bloat" or "waste" to you, while to me it is necessary to undertake my chosen form of interconnection. So my AS, if it appears to you as a single homed AS, is in fact a "single transit homed" AS from your perspective, but that says nothing about any richer form of local interconnection that is not directly related to transit services. * end of substantive comment - ramblings follow - hit delete now! ** and if you read it anyway and want to post a followup then please keep the followup off the ppml mailing list, as its not really relevant to that list - just send to me directly! Wandering further into this area of the role of ASNs for routing , just for a second, the semantics of an ASN has changed over time - As I understand it, the original model of some decades ago equated an AS to both an interior routing domain and the coupling of this domain to an origination of a collection of prefixes that shared the same routing policy. Over the years the "shared the same routing policy" has disappeared, and now the prefix is the element of routing policy, while the AS is, in effect, the labelling of an interior routing domain. If we ever want to use these tokens for more than what they are today (today, strictly speaking, ASNs form the BGP path metric of last resort and the protocol's loop detector, and their use in the area of routing policy expression is an adornment of the original semantic intent rather than a core feature) and, specifically if we want to use ASNs as forwarding tokens, then, yes the ASN distribution policies would need to accommodate the aspect of one routing domain wanting to express multiple external routing policies using, in such a case, multiple AS numbers. (was that really one sentence? I think less coffee is called for! :-)) Its not bloat, nor is it waste. Its just numbers with meanings! Geoff At 03:30 AM 15/11/2006, Azinger, Marla wrote: >Bloat may be a bad word to use. How about 'waste'? From info at arin.net Tue Nov 21 16:14:32 2006 From: info at arin.net (Member Services) Date: Tue, 21 Nov 2006 16:14:32 -0500 Subject: [ppml] Policy Proposal: Reinstatement of PGP Authentication Method In-Reply-To: <453F67ED.3020306@arin.net> References: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> <453F67ED.3020306@arin.net> Message-ID: <45636C38.5000309@arin.net> On 2 November 2006 the ARIN Advisory Council (AC) reviewed Reinstatement of PGP Authentication Method and did not accept it at this time as a formal policy proposal. The AC will work with the author to revise the text prior to taking further action. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.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) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is presented; > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, 3. Not accept the > proposal as a formal policy proposal. > > This proposal was received within 10 days of the next scheduled meeting > of the ARIN Advisory Council; the review period may be extended to the > regularly scheduled meeting that occurs after the upcoming meeting. > > If the AC accepts the proposal or reaches an agreement with the author, > then the proposal will be posted as a formal policy proposal to PPML and > it will be presented at a Public Policy Meeting. If the AC does not > accept the proposal or can not reach an agreement with the author, then > the AC will notify the community of their decision with an explanation; > at that time the author may elect to use the petition process to advance > their proposal. If the author elects not to petition or the petition > fails, then the proposal will be considered closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Reinstatement of PGP Authentication Method > > Authors: > Paul Vixie > Mark Kosters > Chris Morrow > Jared Mauch > Bill Woodcock > > Submission Date: Tuesday, October 24, 2006 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > ADDITION TO NRPM > > 3.5 Authentication Methods > ARIN supports three authentication methods for > communication with resource recipients. > > 3.5.1 Mail-From > This section intentionally left blank. > > 3.5.2 PGP > ARIN accepts PGP-signed email as authentic > communication from authorized Points of Contact. POCs > may denote their records "crypt-auth," subsequent to > which unsigned communications shall not be deemed > authentic with regard to those records. > > 3.5.3 X.509 > This section intentionally left blank. > > UPDATES TO TEMPLATES > > ARIN shall include the auth-type field in request templates as > necessary to distinguish between cryptographic and mail-from > authentication methods. > > UPDATES TO DOCUMENTATION > > ARIN shall update documentation as appropriate, to explain the > differences between mail-from, PGP, and X.509 authentication > methods. > > KEY USE IN COMMUNICATION: > > ARIN shall accept PGP-signed communications, validate the > signature, compare it to the identity of the authorized POCs > for records referenced in the correspondence, and act > appropriately based upon the validity or invalidity of the > signature. > > ARIN shall PGP-sign all outgoing hostmaster email with the > hostmaster role key, and staff members may optionally also > sign mail which they originate with their own individual keys. > > ARIN shall accept PGP-encrypted communications > which are encrypted using ARIN's hostmaster public key. > > ARIN shall not encrypt any outgoing communications, except by > explicit mutual prior agreement with the recipient. > > NON-BINDING RECOMMENDED KEY MANAGEMENT PRACTICES: > > It is recommended that ARIN utilize normal POC-verification > processes as necessary to accommodate users who lose the > private key or passphrase associated with the POCs for their > crypt-auth protected resources. > > It is recommended that ARIN exercise reasonable caution in > preventing the proliferation of copies of the hostmaster > private key and passphrase. > > It is recommended that ARIN print out a copy of the private key > and passphrase, and secure them in a safe-deposit box outside > of ARIN's physical premises, which any two ARIN officers might > access in the event that the operating copy of the key is lost > or compromised. > > It is recommended that ARIN publish the hostmaster public key > on the ARIN web site, in a manner similar to that of the other > RIRs: > http://lacnic.net/hostmaster-pub-key.txt > https://www.ripe.net/rs/pgp/ncc-pgpkey-2006.asc > ftp://ftp.apnic.net/pub/zones/PUBLIC_KEY > > It is recommended that ARIN publish the hostmaster public key > by submitting it to common PGP keyservers which, among others, > might include: > pgp.mit.edu > www.pgp.net > > It is recommended that ARIN attempt to cross-sign the > hostmaster PGP keys of the other four RIRs and ICANN. > > It is recommended that ARIN's hostmaster public key be signed > by members of the ARIN board of trustees. > > Rationale: > > Globally, PGP is the most commonly used cryptographic > authentication method between RIRs and resource recipients who > wish to protect their resource registration records against > unauthorized modification. The PGP-auth authentication method > is supported by RIPE, APNIC, LACNIC, and AfriNIC, and it was > historically supported by the InterNIC prior to ARIN's > formation. By contrast, current ARIN resource recipients have > only two options: "mail-from," which is trivially spoofed and > should not be relied upon to protect important database > objects, and X.509, which involves a rigorous and lengthy > proof-of-identity process and compels use of a compatible MUA, > a combination which has dissuaded virtually all of ARIN's > constituents. > > There isn't a lot of work to do here, and certainly nothing > tricky. The hostmaster key has existed since InterNIC days, and > ARIN staff have verified that the key and passphrase are still > known and working fine. This is simple code, which all the > other RIRs deployed without a second thought or complaint. If > RIPE and APNIC have always done this, the InterNIC did it > before ARIN was formed, and LACNIC and AfriNIC took this for > granted as a part of their startup process, we see no reason > why ARIN should be the only RIR to not offer this most basic of > protections to its members. > > We need to get PGP support reinstated, so that our records can > be protected against hijacking and vandalism, and so we won't > look like idiots as the only one of the five regions that can't > figure this stuff out. > > Timetable for implementation: Immediate > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From info at arin.net Tue Nov 21 16:15:21 2006 From: info at arin.net (Member Services) Date: Tue, 21 Nov 2006 16:15:21 -0500 Subject: [ppml] Policy Proposal: Documentation of the Mail-From Authentication Method In-Reply-To: <453F67F8.5050307@arin.net> References: <453F67F8.5050307@arin.net> Message-ID: <45636C69.1020507@arin.net> On 2 November 2006 the ARIN Advisory Council (AC) reviewed Documentation of the Mail-From Authentication Method and did not accept it at this time as a formal policy proposal. The AC will work with the author to revise the text prior to taking further action. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.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) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is presented; > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, 3. Not accept the > proposal as a formal policy proposal. > > This proposal was received within 10 days of the next scheduled meeting > of the ARIN Advisory Council; the review period may be extended to the > regularly scheduled meeting that occurs after the upcoming meeting. > > If the AC accepts the proposal or reaches an agreement with the author, > then the proposal will be posted as a formal policy proposal to PPML and > it will be presented at a Public Policy Meeting. If the AC does not > accept the proposal or can not reach an agreement with the author, then > the AC will notify the community of their decision with an explanation; > at that time the author may elect to use the petition process to advance > their proposal. If the author elects not to petition or the petition > fails, then the proposal will be considered closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Documentation of the Mail-From Authentication Method > > Authors: > Paul Vixie > Mark Kosters > Chris Morrow > Jared Mauch > Bill Woodcock > > Proposal Version: 1 > > Submission Date: Tuesday, October 24, 2006 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > DELETION FROM THE NRPM > > 3.5.1 Mail-From > This section intentionally left blank. > > ADDITION TO THE NRPM > > 3.5.1 Mail-From > Mail-From is the default authentication method by which > registration records are protected from vandalism. If a > registrant fails to designate a more secure method, any > subsequent email which bears the sender address of an > authorized Point of Contact may be deemed authentic with > regard to the registrant's records. Since it is trivial > to forge a sender address, Mail-From should not be > regarded as secure. Use of Mail-From authentication is > not recommended to any registrant who has the means to > implement either of the more secure cryptographic > authentication methods. > Rationale: > > This policy complements the previously-proposed "Reinstatement of > PGP Authentication Method" which introduces section 3.5 to the > NRPM. Section 3.5 relates the existence of three authentication > methods. Two of those, mail-from and X.509, were preexisting but > not documented within the NRPM. > > This policy proposal simply seeks to provide brief documentation > of the existence of the mail-from authentication method. Because > the specific wording of the documentation may be subject to > debate, and is in no way interdependent upon the documentation of > the other two methods, it is being proposed in a separate policy, > so that consensus may be more easily reached. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From info at arin.net Tue Nov 21 16:17:06 2006 From: info at arin.net (Member Services) Date: Tue, 21 Nov 2006 16:17:06 -0500 Subject: [ppml] Policy Proposal: Documentation of the X.509 Authentication Method In-Reply-To: <453F6805.3010100@arin.net> References: <453F6805.3010100@arin.net> Message-ID: <45636CD2.60202@arin.net> On 2 November 2006 the ARIN Advisory Council (AC) reviewed Documentation of the X.509 Authentication Method and did not accept it at this time as a formal policy proposal. The AC will work with the author to revise the text prior to taking further action. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.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) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is presented; > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, 3. Not accept the > proposal as a formal policy proposal. > > This proposal was received within 10 days of the next scheduled meeting > of the ARIN Advisory Council; the review period may be extended to the > regularly scheduled meeting that occurs after the upcoming meeting. > > If the AC accepts the proposal or reaches an agreement with the author, > then the proposal will be posted as a formal policy proposal to PPML and > it will be presented at a Public Policy Meeting. If the AC does not > accept the proposal or can not reach an agreement with the author, then > the AC will notify the community of their decision with an explanation; > at that time the author may elect to use the petition process to advance > their proposal. If the author elects not to petition or the petition > fails, then the proposal will be considered closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Documentation of the X.509 Authentication Method > > Authors: > Paul Vixie > Mark Kosters > Chris Morrow > Jared Mauch > Bill Woodcock > > Proposal Version: 1 > > Submission Date: Tuesday, October 24, 2006 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > DELETION FROM THE NRPM > > 3.5.3 X.509 > This section intentionally left blank. > > ADDITION TO THE NRPM > > 3.5.3 X.509 > ARIN accepts X.509-signed transactions as authentic > communication from authorized Points of Contact. POCs > may denote their records "crypt-auth," subsequent to > which unsigned communications shall not be deemed > authentic with regard to those records. > > Rationale: > > This policy complements the previously-proposed "Reinstatement of > PGP Authentication Method" which introduces section 3.5 to the > NRPM. Section 3.5 relates the existence of three authentication > methods. Two of those, mail-from and X.509, were preexisting but > not documented within the NRPM. > > This policy proposal simply seeks to provide brief documentation > of the existence of the X.509 authentication method. Because the > specific wording of the documentation may be subject to debate, > and is in no way interdependent upon the documentation of the > other two methods, it is being proposed in a separate policy, so > that consensus may be more easily reached. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From info at arin.net Wed Nov 22 12:39:59 2006 From: info at arin.net (Member Services) Date: Wed, 22 Nov 2006 12:39:59 -0500 Subject: [ppml] Policy Implementation Schedule Message-ID: <45648B6F.5000809@arin.net> On 16 November 2006 the ARIN Board of Trustees adopted two policy proposals. The proposals and their expected implementation dates are listed below. * 2006-2: Micro-allocations for Internal Infrastructure - Not later than 20 December 2006. * 2006-3: Capturing Originations in Templates - Not later than 30 March 2007. As final implementation details are determined exact implementation dates of these policies will be published. Policy proposal texts are available at the Policy Proposal Archive which can be found at: http://www.arin.net/policy/proposal_archive.html Regards, Member Services Department American Registry for Internet Numbers From Michael.Dillon at btradianz.com Wed Nov 29 02:53:52 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 29 Nov 2006 07:53:52 +0000 Subject: [ppml] Nonsense regarding n-byte ASNs Message-ID: Those who were disturbed by all the nonsense about n-byte ASNs may be interested to note that the IESG also considers ASNs to be just some numbers that are bigger than 65535 >To: IANA >From: IESG Secretary >Date: Mon, 27 Nov 2006 09:56:13 -0500 >Cc: iesg at ietf.org >Subject: The IESG Approved the Expansion of the AS Number Registry > >Dear IANA, > >The IESG has approved the expansion of the size of the AS Number >registry described in draft-ietf-idr-as4bytes-12.txt before the approval >of the document. Please expand the AS Number space to include the >values 65536 through 4294967295, initially marked as "Held by IANA". > >Allocations can be made to the RIRs prior to the publication of >this RFC. > >Thank You, >The IESG ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at btradianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com One Community One Connection One Focus