From Michael.Dillon at btradianz.com Mon Apr 3 05:08:11 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 3 Apr 2006 10:08:11 +0100 Subject: [ppml] proposed updates to 2006-4 In-Reply-To: <20060331173827.7987.qmail@hoster908.com> Message-ID: > 1. We should reserve a larger block than a /44. Reserving larger > blocks at this point can likely only benefit us in the future as > networks grow. I've proposed updating 2006-4 to a /40 reserved > block, but I'm open to discussing larger blocks if people think thatis needed. Reservation of blocks was introduced for ISPs because ISP networks are continually growing. This policy is intended to apply to non-ISPs who do not experience the same scale of network growth as ISPs. It should be able to assess an applicant's overall needs and assign a single block that will suit 99% of applicants for the foreseeable future. Rather than reserving space, we need to have a sensible assessment of the applicant's address needs, both now and in the foreseeable future. --Michael Dillon From sleibrand at internap.com Mon Apr 3 08:58:26 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 3 Apr 2006 08:58:26 -0400 (EDT) Subject: [ppml] proposed updates to 2006-4 In-Reply-To: References: Message-ID: Does anyone know whether ARIN currently uses sparse allocations (reserved blocks) for IPv4 PI space? -Scott On 04/03/06 at 10:08am +0100, Michael.Dillon at btradianz.com wrote: > > 1. We should reserve a larger block than a /44. Reserving larger > > blocks at this point can likely only benefit us in the future as > > networks grow. I've proposed updating 2006-4 to a /40 reserved > > block, but I'm open to discussing larger blocks if people think that is > needed. > > Reservation of blocks was introduced for ISPs because > ISP networks are continually growing. This policy is intended > to apply to non-ISPs who do not experience the same scale > of network growth as ISPs. It should be able to assess an > applicant's overall needs and assign a single block that > will suit 99% of applicants for the foreseeable future. > > Rather than reserving space, we need to have a sensible > assessment of the applicant's address needs, both now > and in the foreseeable future. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From memsvcs at arin.net Mon Apr 3 19:07:21 2006 From: memsvcs at arin.net (Member Services) Date: Mon, 03 Apr 2006 19:07:21 -0400 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - revised text Message-ID: <4431AAA9.802@arin.net> Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites has been revised by the author. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2006_4.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites Policy Proposal 2006-4, version 2 Proposal type: new Policy term: permanent Policy statement: Add new subsection to the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct end site assignment, an organization must meet all of the following criteria: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv4; 4. have a direct assignment from ARIN of at least a IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 equivalent. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /48 out of a reserved /44. Organizations with multiple ASNs may be assigned a prefix large enough to permit a /48 to be assigned to each ASN. Direct Assignments shall be allocated from a separate super-block to allow for LIRs to filter. 6.5.8.3. Subsequent direct assignments to end sites Organization's assignment size may be increased to the next larger prefix (to a maximum of /44) when the organization demonstrates any of the following criteria: 1. 50% of the assigned /64 subnets are utilized 2. 50% of the /48 subnets are assigned and utilized to unique ASN assignments Organizations which request and can justify assignments larger than /44 shall qualify as LIRs and must make application for an allocation under policies applicable to an LIR, except that they shall be exempted from the requirement to assign addresses to other organizations. Only one direct assignment may be made to an end site organization under Section 6.5.8 Policy Rationale This policy is proposed as an alternative to the existing 2005-1 policy proposal. This policy is intended to be more conservative that the existing proposed 2005-1 policy. While this policy does allow PI assignments to end-sites, it limits the scope to current IPv4 holders with direct assignments. A more conservative policy is desirable as the first IPv6 PI policy. Current ARIN policy does not permit an end-site from obtaining a Provider Independent IPv6 address block directly from ARIN. There is currently no viable IPv6 multihoming method available for these end-sites. Shim6 & other methods have been proposed as a possible method to meet multihoming requirements. Today, no implementation or alternatives exist to ?traditional? IPv4 multihoming which announces unique address space from an ASN. The largest end-sites (corporations & content providers) have the greatest to gain and/or lose by not having an available method to multihome. While IPv6 provides for stateless auto configuration for end hosts, no new methods for renumbering the infrastructure are available. The cost and complexity of renumbering these large organizations makes it essential to provide stable address resources which are not assigned from a LIR. The lack of an end-site assignment policy is currently preventing the real planning and deployment of IPv6 networks in these organizations. Other policy proposals (2005-1) addressing this issue have been presented at the ARIN 15 & 16 meetings. This policy proposal attempts to address the issues that were raised on the ppml mailing list and at the public policy meetings for 2005-1. Specifically, the main issue surrounding the creation of consensus on this policy appears to be the criteria for which end-sites should be able to obtain an endsite assignment. Concerns have been raised about the creation of a new IPv6 ?swamp? by having a policy that is too lenient. This issue is addressed in the policy by limiting the endsite assignments to current organizations with a modest IPv4 assignment. The assignment of IPv4 resources is orthogonal to the assignment of IPv6 addresses. However, the use of existing IPv4 assignments and ARIN membership are postulated as an appropriate regulator for the initial assignments under an IPv6 endsite policy. It is reasonable to consider changes to the membership and IPv4 assignment requirements in the future. This review should be conducted after the endsite assignment policy has been in place long enough to understand the demand for endsite IPv6 assignments and the development of IPv6 networks have matured. This policy proposal does not attempt to address the assignment needs for endsites which currently do not have IPv4 assignments. Timetable for implementation: within 90 days of approval by the BoT From sleibrand at internap.com Mon Apr 3 19:37:54 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 3 Apr 2006 19:37:54 -0400 (EDT) Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - revised text In-Reply-To: <4431AAA9.802@arin.net> References: <4431AAA9.802@arin.net> Message-ID: Andrew, This text doesn't seem to match my reading of your proposed revisions from your recent message(s). Can you give us a diff of the changes and rationale for them? Thanks, Scott On 04/03/06 at 7:07pm -0400, Member Services wrote: > Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites has > been revised by the author. This proposal is open for discussion on this > mailing list and will be on the agenda at the upcoming ARIN Public > Policy Meeting. > > The current policy proposal text is provided below and is also available > at: http://www.arin.net/policy/proposals/2006_4.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites > > Policy Proposal 2006-4, version 2 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add new subsection to the NRPM: > > 6.5.8. Direct assignments to end sites > > 6.5.8.1. To qualify for a direct end site assignment, an > organization must meet all of the following criteria: > > 1. not be an LIR; > 2. be an end site; > 3. be currently multihomed using IPv4; > 4. have a direct assignment from ARIN of at least a IPv4 /19 > and can show the current utilization of 80% of an IPv4 /19 equivalent. > > 6.5.8.2. Direct assignment size to end sites > > Organizations that meet the direct end site assignment criteria are > eligible to receive a direct assignment of /48 out of a reserved /44. > Organizations with multiple ASNs may be assigned a prefix large enough > to permit a /48 to be assigned to each ASN. > > Direct Assignments shall be allocated from a separate super-block > to allow for LIRs to filter. > > 6.5.8.3. Subsequent direct assignments to end sites > > Organization's assignment size may be increased to the next larger > prefix (to a maximum of /44) when the organization demonstrates any of > the following criteria: > > 1. 50% of the assigned /64 subnets are utilized > 2. 50% of the /48 subnets are assigned and utilized to unique > ASN assignments > > Organizations which request and can justify assignments larger than /44 > shall qualify as LIRs and must make application for an allocation under > policies applicable to an LIR, except that they shall be exempted from > the requirement to assign addresses to other organizations. > > Only one direct assignment may be made to an end site organization under > Section 6.5.8 > > Policy Rationale > > This policy is proposed as an alternative to the existing 2005-1 policy > proposal. This policy is intended to be more conservative that the > existing proposed 2005-1 policy. While this policy does allow PI > assignments to end-sites, it limits the scope to current IPv4 holders > with direct assignments. A more conservative policy is desirable as the > first IPv6 PI policy. > > Current ARIN policy does not permit an end-site from obtaining a > Provider Independent IPv6 address block directly from ARIN. There is > currently no viable IPv6 multihoming method available for these > end-sites. Shim6 & other methods have been proposed as a possible method > to meet multihoming requirements. Today, no implementation or > alternatives exist to ?traditional? IPv4 multihoming which announces > unique address space from an ASN. > > The largest end-sites (corporations & content providers) have the > greatest to gain and/or lose by not having an available method to > multihome. While IPv6 provides for stateless auto configuration for end > hosts, no new methods for renumbering the infrastructure are available. > The cost and complexity of renumbering these large organizations makes > it essential to provide stable address resources which are not assigned > from a LIR. > > The lack of an end-site assignment policy is currently preventing the > real planning and deployment of IPv6 networks in these organizations. > > Other policy proposals (2005-1) addressing this issue have been > presented at the ARIN 15 & 16 meetings. This policy proposal attempts to > address the issues that were raised on the ppml mailing list and at the > public policy meetings for 2005-1. > > Specifically, the main issue surrounding the creation of consensus on > this policy appears to be the criteria for which end-sites should be > able to obtain an endsite assignment. Concerns have been raised about > the creation of a new IPv6 ?swamp? by having a policy that is too > lenient. This issue is addressed in the policy by limiting the endsite > assignments to current organizations with a modest IPv4 assignment. > > The assignment of IPv4 resources is orthogonal to the assignment of IPv6 > addresses. However, the use of existing IPv4 assignments and ARIN > membership are postulated as an appropriate regulator for the initial > assignments under an IPv6 endsite policy. It is reasonable to consider > changes to the membership and IPv4 assignment requirements in the > future. This review should be conducted after the endsite assignment > policy has been in place long enough to understand the demand for > endsite IPv6 assignments and the development of IPv6 networks have matured. > > This policy proposal does not attempt to address the assignment needs > for endsites which currently do not have IPv4 assignments. > > Timetable for implementation: within 90 days of approval by the BoT > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From andrew.dul at quark.net Mon Apr 3 19:44:34 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Mon, 03 Apr 2006 23:44:34 +0000 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - revised text Message-ID: <20060403234434.28405.qmail@hoster908.com> > -------Original Message------- > From: Scott Leibrand > Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - revised text > Sent: 03 Apr '06 15:37 > > Andrew, > > This text doesn't seem to match my reading of your proposed revisions from > your recent message(s). Can you give us a diff of the changes and > rationale for them? I added the text to allow a /48 per ASN. The text is different than what was originally posted on the list last week. Thanks to those in the background who helped cleanup the text. The intent of what I proposed last week is unchanged. The reserved /44 remains unchanged. There didn't seem to be any vocal support for a larger (/40) reserved block. Andrew From sleibrand at internap.com Mon Apr 3 20:03:36 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 3 Apr 2006 20:03:36 -0400 (EDT) Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - revised text In-Reply-To: <20060403234434.28405.qmail@hoster908.com> References: <20060403234434.28405.qmail@hoster908.com> Message-ID: On 04/03/06 at 11:44pm -0000, Andrew Dul wrote: > I added the text to allow a /48 per ASN. The text is different than > what was originally posted on the list last week. Thanks to those in > the background who helped cleanup the text. The intent of what I > proposed last week is unchanged. Ok, cool... > The reserved /44 remains unchanged. There didn't seem to be any vocal > support for a larger (/40) reserved block. Ah, ok. That explains my confusion. Thanks for clarifying. -Scott From tme at multicasttech.com Mon Apr 3 20:33:40 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 3 Apr 2006 20:33:40 -0400 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - revised text In-Reply-To: <20060403234434.28405.qmail@hoster908.com> References: <20060403234434.28405.qmail@hoster908.com> Message-ID: <75FDFB14-27C5-46B2-924B-06B7E82715DF@multicasttech.com> Dear Andrew; A question : it says 6.5.8.1. To qualify for a direct end site assignment, an organization must meet all of the following criteria: 2. be an end site; Is "end site" clearly defined somewhere ? A large (or even not so large) corporation may well act as a transit provider to remote corporate locations; I would argue that the entire entity is a end site, no matter how distributed, but I just wanted to make this clear. Regards Marshall Eubanks On Apr 3, 2006, at 7:44 PM, Andrew Dul wrote: >> -------Original Message------- >> From: Scott Leibrand >> Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI >> Assignments for End Sites - revised text >> Sent: 03 Apr '06 15:37 >> >> Andrew, >> >> This text doesn't seem to match my reading of your proposed >> revisions from >> your recent message(s). Can you give us a diff of the changes and >> rationale for them? > > I added the text to allow a /48 per ASN. The text is different > than what was originally posted on the list last week. Thanks to > those in the background who helped cleanup the text. The intent of > what I proposed last week is unchanged. > > The reserved /44 remains unchanged. There didn't seem to be any > vocal support for a larger (/40) reserved block. > > Andrew > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Tue Apr 4 04:57:14 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 4 Apr 2006 09:57:14 +0100 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - revised text In-Reply-To: <4431AAA9.802@arin.net> Message-ID: > Organizations which request and can justify assignments larger than /44 > shall qualify as LIRs and must make application for an allocation under > policies applicable to an LIR, except that they shall be exempted from > the requirement to assign addresses to other organizations. Given the organized structure of the NPRM and the fact that this policy proposal attempts to change more than one part of it, I think that this needs to be EXPLICITLY stated as a an addition or a change to a specific section of the NPRM. Are you saying that you want to change the wording of 6.5.1.1 a) and b) to say a) be an LIR or an end-site which can justify more than a /44 under the requirements of section ?.?.?.? We can't just leave this to the whims of an editor after the fact and we should not write proposals in a way that obscures what they are doing to the core policy. By the way, this is only one of many problems that I see in this proposal. --Michael Dillon From billd at cait.wustl.edu Tue Apr 4 08:23:56 2006 From: billd at cait.wustl.edu (billd at cait.wustl.edu) Date: Tue, 4 Apr 2006 07:23:56 -0500 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - revised text Message-ID: I'm not aware of a 'sanctioned' definition of end-site. I would suggest that it implies that the organization's network is not used to provide for-fee transit to other networks not under their own management. In addition, depending upon architecture and communication strategy, an organization might choose to deem a particular element of it's distributed network a separate end-site, or consider the entire distributed infrastructure a single end-site. Bill Darte > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Marshall Eubanks > Sent: Monday, April 03, 2006 7:34 PM > To: Andrew Dul > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI > Assignments for End Sites - revised text > > > Dear Andrew; > > A question : it says > > 6.5.8.1. To qualify for a direct end site assignment, > an organization must meet all of the following criteria: > > > 2. be an end site; > > > Is "end site" clearly defined somewhere ? > > A large (or even not so large) corporation may well act as a transit > provider to remote corporate locations; > I would argue that the entire entity is a end site, no matter how > distributed, but I just wanted to make > this clear. > > Regards > Marshall Eubanks > > On Apr 3, 2006, at 7:44 PM, Andrew Dul wrote: > > >> -------Original Message------- > >> From: Scott Leibrand > >> Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI > >> Assignments for End Sites - revised text > >> Sent: 03 Apr '06 15:37 > >> > >> Andrew, > >> > >> This text doesn't seem to match my reading of your proposed > >> revisions from > >> your recent message(s). Can you give us a diff of the changes and > >> rationale for them? > > > > I added the text to allow a /48 per ASN. The text is different > > than what was originally posted on the list last week. Thanks to > > those in the background who helped cleanup the text. The > intent of > > what I proposed last week is unchanged. > > > > The reserved /44 remains unchanged. There didn't seem to be any > > vocal support for a larger (/40) reserved block. > > > > Andrew > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From Lee.Howard at stanleyassociates.com Tue Apr 4 09:48:46 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 4 Apr 2006 09:48:46 -0400 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB401B1242E@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Marshall Eubanks > Sent: Monday, April 03, 2006 8:34 PM > To: Andrew Dul > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI > Assignments forEnd Sites - revised text > > Dear Andrew; > > A question : it says > > 6.5.8.1. To qualify for a direct end site assignment, an > organization must meet all of the following criteria: > > > 2. be an end site; > > > Is "end site" clearly defined somewhere ? http://www.arin.net/policy/nrpm.html#six29 6.2.9. End site An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves: that service provider assigning address space to the end user that service provider providing transit service for the end user to other sites that service provider carrying the end user's traffic. that service provider advertising an aggregate prefix route that contains the end user's assignment > > A large (or even not so large) corporation may well act as a transit > provider to remote corporate locations; > I would argue that the entire entity is a end site, no matter how > distributed, but I just wanted to make > this clear. An end site is an organization that gets assignments and transit from an upstream. Under this definition, if an organization gets an (unaggregatable) PI assignment, it is not an end site. A remote office could be considered to be an end site. Lee > > Regards > Marshall Eubanks > > On Apr 3, 2006, at 7:44 PM, Andrew Dul wrote: > > >> -------Original Message------- > >> From: Scott Leibrand > >> Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI > >> Assignments for End Sites - revised text > >> Sent: 03 Apr '06 15:37 > >> > >> Andrew, > >> > >> This text doesn't seem to match my reading of your proposed > >> revisions from > >> your recent message(s). Can you give us a diff of the changes and > >> rationale for them? > > > > I added the text to allow a /48 per ASN. The text is different > > than what was originally posted on the list last week. Thanks to > > those in the background who helped cleanup the text. The > intent of > > what I proposed last week is unchanged. > > > > The reserved /44 remains unchanged. There didn't seem to be any > > vocal support for a larger (/40) reserved block. > > > > Andrew > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From billd at cait.wustl.edu Tue Apr 4 10:20:35 2006 From: billd at cait.wustl.edu (billd at cait.wustl.edu) Date: Tue, 4 Apr 2006 09:20:35 -0500 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - revised text Message-ID: So an organization that receives a PI assignment from ARIN is NOT and end-site.... As such, the policy proposal 2006-4 as written there is NO chance for an organization to qualify....as #2 and #4 are mutually exclusive....? 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv4; 4. have a direct assignment from ARIN of at least a IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 equivalent. Bill Darte > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Howard, W. Lee > Sent: Tuesday, April 04, 2006 8:49 AM > To: Marshall Eubanks; Andrew Dul > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI > Assignments forEnd Sites - revised text > > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Marshall Eubanks > > Sent: Monday, April 03, 2006 8:34 PM > > To: Andrew Dul > > Cc: ppml at arin.net > > Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI > > Assignments forEnd Sites - revised text > > > > Dear Andrew; > > > > A question : it says > > > > 6.5.8.1. To qualify for a direct end site assignment, an > > organization must meet all of the following criteria: > > > > > > 2. be an end site; > > > > > > Is "end site" clearly defined somewhere ? > > http://www.arin.net/policy/nrpm.html#six29 > > 6.2.9. End site > An end site is defined as an end user (subscriber) who has a > business relationship with a service provider that involves: > > that service provider assigning address space to the end user > that service provider providing transit service for the end > user to other sites > that service provider carrying the end user's traffic. > that service provider advertising an aggregate prefix route > that contains the end user's assignment > > > > > > > > A large (or even not so large) corporation may well act as a transit > > provider to remote corporate locations; > > I would argue that the entire entity is a end site, no matter how > > distributed, but I just wanted to make > > this clear. > > An end site is an organization that gets assignments and transit > from an upstream. Under this definition, if an organization > gets an (unaggregatable) PI assignment, it is not an end > site. A remote office could be considered to be an end site. > > Lee > > > > > > Regards > > Marshall Eubanks > > > > On Apr 3, 2006, at 7:44 PM, Andrew Dul wrote: > > > > >> -------Original Message------- > > >> From: Scott Leibrand > > >> Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI > > >> Assignments for End Sites - revised text > > >> Sent: 03 Apr '06 15:37 > > >> > > >> Andrew, > > >> > > >> This text doesn't seem to match my reading of your proposed > > >> revisions from > > >> your recent message(s). Can you give us a diff of the > changes and > > >> rationale for them? > > > > > > I added the text to allow a /48 per ASN. The text is different > > > than what was originally posted on the list last week. > Thanks to > > > those in the background who helped cleanup the text. The > > intent of > > > what I proposed last week is unchanged. > > > > > > The reserved /44 remains unchanged. There didn't seem to be any > > > vocal support for a larger (/40) reserved block. > > > > > > Andrew > > > _______________________________________________ > > > PPML mailing list > > > PPML at arin.net > > > http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From tme at multicasttech.com Tue Apr 4 10:24:01 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 4 Apr 2006 10:24:01 -0400 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401B1242E@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB401B1242E@CL-S-EX-1.stanleyassociates.com> Message-ID: <09D209FA-7754-4C6B-BD03-AC709983F22F@multicasttech.com> Hello; On Apr 4, 2006, at 9:48 AM, Howard, W. Lee wrote: > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of Marshall Eubanks >> Sent: Monday, April 03, 2006 8:34 PM >> To: Andrew Dul >> Cc: ppml at arin.net >> Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI >> Assignments forEnd Sites - revised text >> >> Dear Andrew; >> >> A question : it says >> >> 6.5.8.1. To qualify for a direct end site assignment, an >> organization must meet all of the following criteria: >> >> >> 2. be an end site; >> >> >> Is "end site" clearly defined somewhere ? > > http://www.arin.net/policy/nrpm.html#six29 > > 6.2.9. End site > An end site is defined as an end user (subscriber) who has a business > relationship with a service provider that involves: > > that service provider assigning address space to the end user > that service provider providing transit service for the end user to > other sites > that service provider carrying the end user's traffic. > that service provider advertising an aggregate prefix route that > contains the end user's assignment > > > As I read this, an end site cannot be multi-homed, so how can conditions 2 and 3 be simultaneously met ? 2. be an end site; 3. be currently multihomed using IPv4; > >> >> A large (or even not so large) corporation may well act as a transit >> provider to remote corporate locations; >> I would argue that the entire entity is a end site, no matter how >> distributed, but I just wanted to make >> this clear. > > An end site is an organization that gets assignments and transit > from an upstream. Under this definition, if an organization gets > an (unaggregatable) PI assignment, it is not an end site. A > remote office could be considered to be an end site. > So, if a company has 128 small remote offices, each with a fully used internal IPv4 /24 , and uses a /20 at HQ, neither it nor its offices would qualify ? > Lee Regards Marshall > > >> >> Regards >> Marshall Eubanks >> >> On Apr 3, 2006, at 7:44 PM, Andrew Dul wrote: >> >>>> -------Original Message------- >>>> From: Scott Leibrand >>>> Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI >>>> Assignments for End Sites - revised text >>>> Sent: 03 Apr '06 15:37 >>>> >>>> Andrew, >>>> >>>> This text doesn't seem to match my reading of your proposed >>>> revisions from >>>> your recent message(s). Can you give us a diff of the changes and >>>> rationale for them? >>> >>> I added the text to allow a /48 per ASN. The text is different >>> than what was originally posted on the list last week. Thanks to >>> those in the background who helped cleanup the text. The >> intent of >>> what I proposed last week is unchanged. >>> >>> The reserved /44 remains unchanged. There didn't seem to be any >>> vocal support for a larger (/40) reserved block. >>> >>> Andrew >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> From Michael.Dillon at btradianz.com Tue Apr 4 10:43:14 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 4 Apr 2006 15:43:14 +0100 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401B1242E@CL-S-EX-1.stanleyassociates.com> Message-ID: It would be really helpful if the IAB would comment on the original thinking behind the IPv6 /48. There is far more uncertainty about this issue than there should be at this late date. > 6.2.9. End site > An end site is defined as an end user (subscriber) who has a business > relationship with a service provider that involves: > An end site is an organization that gets assignments and transit > from an upstream. Under this definition, if an organization gets > an (unaggregatable) PI assignment, it is not an end site. A > remote office could be considered to be an end site. I think that is overly simplistic. For instance, consider the case of a single human being who owns two homes, one in the country and one in the city. How many service providers would NOT open a second subscriber account if this individual decided to buy IPv6 Internet access for their second home from the same provider? How many of these providers would only supply a single /48 subnet for both locations? I suspect that the answer is that NOBODY treats a single human with multiple locations as a single subscriber. If you look at a similar IPv4 situation with non-cable-TV providers, I think you will find that both locations are assigned their own IPv4 address. Unfortunately, the term "subscriber" is not used in the IPv4 policy except to refer to a cable-TV subscriber special case. So, in conclusion, I believe that it is more in tune with IPv6 policy to say that an OFFICE of an organization is considered to be an end-site. Remoteness is not an issue. The issue is more one of discrete locations. If the office is in a multi-story office tower, then it gets its own /48. If the office is in a multi-block campus, then it shares a single /48 with the rest of the campus. If this latter seems unfair for a large university or Microsoft in Seattle, let's not forget http://www.arin.net/policy/nrpm.html#six9 which explicitly, in 6.9, notes that very large subscribers are an exception to the /48 rule. Large organizations are not monolithic creatures. They are composed of multiple legal entities and they operate multiple functions out of many different locations, often grouping certain functions into certain locations. They regularly dissect themselves and trade pieces around, i.e. merger and aquisition. To force such organizations to live inside a single /48 means to force them to undertake a tremendous amount of renumbering churn that individual Internet users are not subjected to. However, assigning a single /48 to each physical location (discrete street address) will allow such organizations to carry out a large percentage of M&A activity without absolutely requiring renumbering. They may still need to do pure NAT where their Internet connectivity is centralised or switches providers, but the network architecture designed around an interchangeable /48 network size, will minimize the changes. --Michael Dillon From Michael.Dillon at btradianz.com Tue Apr 4 10:51:58 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 4 Apr 2006 15:51:58 +0100 Subject: [ppml] Direct PI assignments in IPv6 Message-ID: It might help to sort out this policy issue if we imagine what the world would look like if there was no IPv4 network currently in place. In that case, the current Internet would all be addressed using IPv6. All companies would have Internet connections using PA addressing from their upstream providers. We would be discussing a new policy that would allow these companies to migrate from PA IPv6 to PI IPv6. Some companies would have purchased an IPv6 network connection for each office and therefore each office would have its own /48. The entrenched network architecture would make it difficult to renumber into a smaller block of space. Some companies would have a centralised model where their Internet connectivity goes into their main data center and all their offices have frame relay or ATM or IPv6-VPN connections into the data centre. They likely have a single /48 for the entire company or else a /47 under the very large company exception. Our job would be to come up with a sensible policy to allow these companies to transition to PI addressing in a relatively gentle way without much disruption. The reason for transition is that Internet connectivity has now become so important and mission critical that: A) It MUST NOT be disrupted B) It MUST be redundant and multihomed Current proposals to allow PI addressing do not satisfy item A. ------------------------------------------------------- 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 From narten at us.ibm.com Tue Apr 4 11:14:47 2006 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 04 Apr 2006 11:14:47 -0400 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text In-Reply-To: Message from Michael.Dillon@btradianz.com of "Tue, 04 Apr 2006 15:43:14 BST." Message-ID: <200604041514.k34FEl5U025316@cichlid.raleigh.ibm.com> Michael.Dillon at btradianz.com writes: > It would be really helpful if the IAB would comment on > the original thinking behind the IPv6 /48. There is > far more uncertainty about this issue than there should > be at this late date. Not sure what exactly you are asking the IAB. BTW, RFC 3177 presumably says what the IAB was thinking on /48s... > > 6.2.9. End site > > An end site is defined as an end user (subscriber) who has a business > > relationship with a service provider that involves: > > An end site is an organization that gets assignments and transit > > from an upstream. Under this definition, if an organization gets > > an (unaggregatable) PI assignment, it is not an end site. A > > remote office could be considered to be an end site. Just to be clear, the above wording comes from http://www.arin.net/policy/nrpm.html#six, which was developed by the RIRs, not the IAB. > I think that is overly simplistic. Quite possibly. Thomas From sleibrand at internap.com Tue Apr 4 11:20:02 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 4 Apr 2006 11:20:02 -0400 (EDT) Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text In-Reply-To: References: Message-ID: On 04/04/06 at 3:43pm +0100, Michael.Dillon at btradianz.com wrote: > It would be really helpful if the IAB would comment on > the original thinking behind the IPv6 /48. There is > far more uncertainty about this issue than there should > be at this late date. Michael, I think RFC 3177 ("IAB/IESG Recommendations on IPv6 Address Allocations to Sites") addresses that. It would seem more useful IMO for the IETF as a whole to comment on the current thinking regarding IPv6 /48's by taking action on http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt -Scott From Lee.Howard at stanleyassociates.com Tue Apr 4 11:52:59 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 4 Apr 2006 11:52:59 -0400 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB401B1252F@CL-S-EX-1.stanleyassociates.com> I should have been explicit about what's authoritative here. > >> Is "end site" clearly defined somewhere ? > > The following, from ARIN's web site, in the IPv6 section of the Numbering Resource Policy Manual, is official: > > http://www.arin.net/policy/nrpm.html#six29 > > > > 6.2.9. End site > > An end site is defined as an end user (subscriber) who has > a business > > relationship with a service provider that involves: > > > > that service provider assigning address space to the end user > > that service provider providing transit service for the end user to > > other sites > > that service provider carrying the end user's traffic. > > that service provider advertising an aggregate prefix route that > > contains the end user's assignment [end official excerpt] > As I read this, an end site cannot be multi-homed, so > how can conditions 2 and 3 be simultaneously met ? > > 2. be an end site; > 3. be currently multihomed using IPv4; > >> A large (or even not so large) corporation may well act as > a transit > >> provider to remote corporate locations; > >> I would argue that the entire entity is a end site, no matter how > >> distributed, but I just wanted to make > >> this clear. The following is one possible reading of the policy, and is in no way authoritative: > > An end site is an organization that gets assignments and transit > > from an upstream. Under this definition, if an organization gets > > an (unaggregatable) PI assignment, it is not an end site. A > > remote office could be considered to be an end site. > > So, if a company has 128 small remote offices, each with a fully > used internal IPv4 /24 , > and uses a /20 at HQ, neither it nor its offices would qualify ? I couldn't say for sure. Remember that the excerpt above is in the IPv6 section of the NRPM, so I'd try to interpret it in that context. Within the current context of IPv6, there is no policy for assignment to end sites. All IPv6 address assignments under current policy are allocations (or micro-allocations, which might include some non-transit-provider allocations), which is why we have this proposal before us. Lee > Regards > Marshall > > > > > > >> > >> Regards > >> Marshall Eubanks > >> > >> On Apr 3, 2006, at 7:44 PM, Andrew Dul wrote: > >> > >>>> -------Original Message------- > >>>> From: Scott Leibrand > >>>> Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI > >>>> Assignments for End Sites - revised text > >>>> Sent: 03 Apr '06 15:37 > >>>> > >>>> Andrew, > >>>> > >>>> This text doesn't seem to match my reading of your proposed > >>>> revisions from > >>>> your recent message(s). Can you give us a diff of the > changes and > >>>> rationale for them? > >>> > >>> I added the text to allow a /48 per ASN. The text is different > >>> than what was originally posted on the list last week. Thanks to > >>> those in the background who helped cleanup the text. The > >> intent of > >>> what I proposed last week is unchanged. > >>> > >>> The reserved /44 remains unchanged. There didn't seem to be any > >>> vocal support for a larger (/40) reserved block. > >>> > >>> Andrew > >>> _______________________________________________ > >>> PPML mailing list > >>> PPML at arin.net > >>> http://lists.arin.net/mailman/listinfo/ppml > >> > >> _______________________________________________ > >> PPML mailing list > >> PPML at arin.net > >> http://lists.arin.net/mailman/listinfo/ppml > >> > From andrew.dul at quark.net Tue Apr 4 11:53:26 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Tue, 04 Apr 2006 15:53:26 +0000 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text Message-ID: <20060404155326.6337.qmail@hoster908.com> > >> Is "end site" clearly defined somewhere ? > > > > http://www.arin.net/policy/nrpm.html#six29 > > > > 6.2.9. End site > > An end site is defined as an end user (subscriber) who has a business > > relationship with a service provider that involves: > > > > that service provider assigning address space to the end user > > that service provider providing transit service for the end user to > > other sites > > that service provider carrying the end user's traffic. > > that service provider advertising an aggregate prefix route that > > contains the end user's assignment > > > > > > > > As I read this, an end site cannot be multi-homed, so > how can conditions 2 and 3 be simultaneously met ? > > 2. be an end site; > 3. be currently multihomed using IPv4; > We can easily strike the "end site" requirement from the policy proposal if people think that it causes confusion. Andrew From stephen at sprunk.org Tue Apr 4 12:57:27 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 4 Apr 2006 11:57:27 -0500 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text References: Message-ID: <00a101c65808$da9924d0$403816ac@ssprunk> Thus spake > It would be really helpful if the IAB would comment on the original > thinking behind the IPv6 /48. There is far more uncertainty about > this issue than there should be at this late date. We've been 'round and 'round on this before; the definition of "end site" is obviously inadequate. I don't think the IAB (or IETF) is the right group to ask; with all due respect to the v6 architects, decade-old misguided intent is irrelevant. I think it'd be more instructive to see how ARIN itself has been interpreting the term to date, for both IPv4 and IPv6. If there's consensus that they're wrong, we can clarify the policy. ... > So, in conclusion, I believe that it is more in tune with > IPv6 policy to say that an OFFICE of an organization is > considered to be an end-site. Remoteness is not an issue. > The issue is more one of discrete locations. If the office > is in a multi-story office tower, then it gets its own /48. > If the office is in a multi-block campus, then it shares > a single /48 with the rest of the campus. If this latter > seems unfair for a large university or Microsoft in Seattle, > let's not forget http://www.arin.net/policy/nrpm.html#six9 > which explicitly, in 6.9, notes that very large subscribers > are an exception to the /48 rule. I'd propose that a single network with private connectivity between locations should count as a single "site". This roughly correlates with who qualifies for an ASN. If the number of locations/subnets within that AS justifies it, they would qualify for a larger prefix than /48. Consider that if such an org were to get PA space from one or more LIRs, they would get _at most_ one prefix per connection. They would not get a /48 per internal location. Why should PI policy be different? Also, is there a compelling reason for IPv6 policy to be different in this respect from IPv4 policy? I don't think IPv4 policy is currently interpreted the way you're proposing. Not that they need to be the same, but I'd like to see solid reasons (with consensus) on why they should be different. > Large organizations are not monolithic creatures. They are > composed of multiple legal entities and they operate multiple > functions out of many different locations, often grouping > certain functions into certain locations. They regularly > dissect themselves and trade pieces around, i.e. merger and > aquisition. To force such organizations to live inside a single > /48 means to force them to undertake a tremendous amount > of renumbering churn that individual Internet users are not > subjected to. M&A activity involves a lot more than one company buying X locations that previously belonged to another. While some undoubtedly happen that way, it usually involves a subset of users and equipment at several locations, so an entirely new subnet scheme is needed (and/or new locations). Even if an entire location is bought, it will eventually need renumbering anyways to fit with the buyer's internal aggregation when it's rehomed to the new WAN. In short, having a PI /48 per location may allow some network admins to delay the inevitable, but at what cost? > However, assigning a single /48 to each physical location (discrete > street address) will allow such organizations to carry out a large > percentage of M&A activity without absolutely requiring renumbering. For varying values of "large" and "absolutely". If the M&A targets are sufficiently independent to have their own ASN and own private network, I'd agree with that statement -- but at that point, they should qualify as a separate org for the purpose of PI policy and could get their own /48 (or more). No renumbering either way. Giving each location a /48 burns lots of routing slots for little real benefit. > They may still need to do pure NAT where their Internet connectivity > is centralised or switches providers, but the network architecture > designed around an interchangeable /48 network size, will minimize > the changes. The fundamental problem with your model is it creates a situation where, after a few years of M&A, large companies will be advertising hundreds, if not thousands, of unaggregatable /48s per ASN. This _will_ create routing table problems and lead to wholesale filtering of PI space. The goal should be one PI prefix per ASN. Your model starts with that on day one, but it will invariably get worse over time. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From tme at multicasttech.com Tue Apr 4 13:22:36 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 4 Apr 2006 13:22:36 -0400 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text In-Reply-To: <20060404155326.6337.qmail@hoster908.com> References: <20060404155326.6337.qmail@hoster908.com> Message-ID: Dear Andrew; On Apr 4, 2006, at 11:53 AM, Andrew Dul wrote: >>>> Is "end site" clearly defined somewhere ? >>> >>> http://www.arin.net/policy/nrpm.html#six29 >>> >>> 6.2.9. End site >>> An end site is defined as an end user (subscriber) who has a >>> business >>> relationship with a service provider that involves: >>> >>> that service provider assigning address space to the end user >>> that service provider providing transit service for the end user to >>> other sites >>> that service provider carrying the end user's traffic. >>> that service provider advertising an aggregate prefix route that >>> contains the end user's assignment >>> >>> >>> >> >> As I read this, an end site cannot be multi-homed, so >> how can conditions 2 and 3 be simultaneously met ? >> >> 2. be an end site; >> 3. be currently multihomed using IPv4; >> > > We can easily strike the "end site" requirement from the policy > proposal if people think that it causes confusion. > Well, I think it has caused confusion. I originally interpreted this as something like a non-transit AS - a network, regardless of geographic extent, which does not provide any access from one outside network to another. In that case, maybe "end network", with a definition, would be more appropriate. If something else is meant, I think that you need to either spell it out or give a reference. Regards Marshall > Andrew > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From kloch at hotnic.net Tue Apr 4 13:45:35 2006 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 04 Apr 2006 13:45:35 -0400 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text In-Reply-To: <20060404155326.6337.qmail@hoster908.com> References: <20060404155326.6337.qmail@hoster908.com> Message-ID: <4432B0BF.8020400@hotnic.net> >> As I read this, an end site cannot be multi-homed, so >> how can conditions 2 and 3 be simultaneously met ? >> >> 2. be an end site; >> 3. be currently multihomed using IPv4; >> > > > We can easily strike the "end site" requirement from the policy proposal if people think that it causes confusion. This is why the revised 2005-1 includes: 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; and... So organizations that chose to be treated as an ISP under IPv4 policy can choose to be treated as an end site under IPv6 policy. The purpose of that qualifier is only to prohibit an organization from receiving both an LIR and PI assignment. It is a bit redundant to say you must not be an LIR and also must be an end site. A reference to one or the other should be sufficient. - Kevin From kloch at hotnic.net Tue Apr 4 13:55:07 2006 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 04 Apr 2006 13:55:07 -0400 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text In-Reply-To: <00a101c65808$da9924d0$403816ac@ssprunk> References: <00a101c65808$da9924d0$403816ac@ssprunk> Message-ID: <4432B2FB.1040506@hotnic.net> Stephen Sprunk wrote: > We've been 'round and 'round on this before; the definition of "end site" is > obviously inadequate. It is an unfortunate label for a reasonably concept. It is defined by a business relationship with one or more providers, and a lack of such relationships with customers. That seems pretty clear except for cases where large organizations are providing service to departments or other subsidiaries. In that case is it enough to create a provider->customer relationship? The problem is that the label "end site" strongly suggests a charactaristic of physical location which is not at all a part of the thing being defined. Perhaps there is some better label for the concept of "not an isp" than "end site"? Separate from this semantic problem is that some folks appear to prefer a location based concept over an organizational one. - Kevin From Michael.Dillon at btradianz.com Tue Apr 4 15:32:02 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 4 Apr 2006 20:32:02 +0100 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text In-Reply-To: <00a101c65808$da9924d0$403816ac@ssprunk> Message-ID: > I don't think the IAB (or IETF) is the right group to ask; with all due > respect to the v6 architects, decade-old misguided intent is irrelevant. On the contrary. The original IPv6 architects must have considered many possibilities and discarded them for a reason, settling on the idea of a /48 per end-site for a reason. Since their wording is unclear, it would help to understand the surrounding discussion in order to make sense of it. > I > think it'd be more instructive to see how ARIN itself has been interpreting > the term to date, for both IPv4 and IPv6. If there's consensus that they're > wrong, we can clarify the policy. Unfortunately, ARIN does not monitor ISP assignment activity and the only time they would audit or review assignments is when an ISP asks for additional addresses. This means that ARIN has no experience whatsoever with interpreting the meaning of end-sites. That has been done by the ISPs themselves. Now, in the RIPE region it may be different because RIPE does directly involve themselves in ISP assignment activity until they are assured that the ISP can do it in conformance with RIPE policy. On the other hand, RIPE is free to tinker with their IPv6 policy to make it different from ARINs. I don't know how much this has been done. > I'd propose that a single network with private connectivity between > locations should count as a single "site". I would agree. This is a network architectural choice and if the organization chooses this architecture then they would get one /48. In that case, if they wish to receive a PI allocation then it should be a single /48 to be consistent with their architecture. > Consider that if such an org were to get PA space from one or more LIRs, > they would get _at most_ one prefix per connection. They would not get a > /48 per internal location. Why should PI policy be different? If their architecture was to have several connections, whether it was one per physical location or one per regional headquarters, the fact remains, that they have the right to choose their network architecture. If that choice is to get 57 Internet connections with 57 PA /48s, then they should get a PI allocation with enough space to maintain that architecture. On the other hand, if their architecture is based around 3 connections to regional headquarters which then use private networks to the rest of the offices, then that would result in 3 /48's, whether PA or PI. The point is that an organization should have freedom to make their network architecture decisions independent of ARIN policy constraints. IPv6 is about releasing people from constraints. > Also, is there a compelling reason for IPv6 policy to be different in this > respect from IPv4 policy? To release organisations from the scarcity-based constraints of IPv6. > If the M&A targets are sufficiently independent to have their own ASN and > own private network, I'd agree with that statement -- but at that point, > they should qualify as a separate org for the purpose of PI policy and could > get their own /48 (or more). No renumbering either way. Giving each > location a /48 burns lots of routing slots for little real benefit. A /48 does not equal a routing slot. ARIN policy does not mandate all ISPs everywhere to accept a route announcement. > The fundamental problem with your model is it creates a situation where, > after a few years of M&A, large companies will be advertising hundreds, if > not thousands, of unaggregatable /48s per ASN. This _will_ create routing > table problems and lead to wholesale filtering of PI space. That's why I think that PI space should be organized in such a way that it can be aggregated by geographical proximity. I define "geographical proximity" to mean "the nearest city over 100,000", however, it could also be done in a less finely-grained way similar to the way truck dispatchers have divided North America into about a dozen regions. > The goal should be one PI prefix per ASN. Your model starts with that on > day one, but it will invariably get worse over time. You are getting your model and mine mixed together. I want to apply science to ARIN's PI allocation algorithm in order to avoid the worsening which you describe. --Michael Dillon From owen at delong.com Tue Apr 4 15:40:23 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 04 Apr 2006 12:40:23 -0700 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - revised text In-Reply-To: References: Message-ID: Essentially, as I understand it, and end-site is an organization or autonomous system which does not provide transit (does not accept packets from one AS and forward them to other AS(es)). For IP Policy purposes, I believe the RFCs or NRPM (don't remember which at the moment) define end-site as an IP address consumer who is not an [RL]IR. Owen --On April 4, 2006 7:23:56 AM -0500 billd at cait.wustl.edu wrote: > I'm not aware of a 'sanctioned' definition of end-site. > > I would suggest that it implies that the organization's network is not > used to provide for-fee transit to other networks not under their own > management. In addition, depending upon architecture and communication > strategy, an organization might choose to deem a particular element of > it's distributed network a separate end-site, or consider the entire > distributed > infrastructure a single end-site. > > Bill Darte > > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of Marshall Eubanks >> Sent: Monday, April 03, 2006 7:34 PM >> To: Andrew Dul >> Cc: ppml at arin.net >> Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI >> Assignments for End Sites - revised text >> >> >> Dear Andrew; >> >> A question : it says >> >> 6.5.8.1. To qualify for a direct end site assignment, >> an organization must meet all of the following criteria: >> >> >> 2. be an end site; >> >> >> Is "end site" clearly defined somewhere ? >> >> A large (or even not so large) corporation may well act as a transit >> provider to remote corporate locations; >> I would argue that the entire entity is a end site, no matter how >> distributed, but I just wanted to make >> this clear. >> >> Regards >> Marshall Eubanks >> >> On Apr 3, 2006, at 7:44 PM, Andrew Dul wrote: >> >> >> -------Original Message------- >> >> From: Scott Leibrand >> >> Subject: Re: [ppml] Policy Proposal 2006-4: IPv6 Direct PI >> >> Assignments for End Sites - revised text >> >> Sent: 03 Apr '06 15:37 >> >> >> >> Andrew, >> >> >> >> This text doesn't seem to match my reading of your proposed >> >> revisions from >> >> your recent message(s). Can you give us a diff of the changes and >> >> rationale for them? >> > >> > I added the text to allow a /48 per ASN. The text is different >> > than what was originally posted on the list last week. Thanks to >> > those in the background who helped cleanup the text. The >> intent of >> > what I proposed last week is unchanged. >> > >> > The reserved /44 remains unchanged. There didn't seem to be any >> > vocal support for a larger (/40) reserved block. >> > >> > Andrew >> > _______________________________________________ >> > PPML mailing list >> > PPML at arin.net >> > http://lists.arin.net/mailman/listinfo/ppml >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From stephen at sprunk.org Tue Apr 4 18:17:56 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 4 Apr 2006 17:17:56 -0500 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text References: Message-ID: <028c01c65835$a0910f50$403816ac@ssprunk> Thus spake >> I don't think the IAB (or IETF) is the right group to ask; with all due >> respect to the v6 architects, decade-old misguided intent is irrelevant. > > On the contrary. The original IPv6 architects must have considered > many possibilities and discarded them for a reason, settling on > the idea of a /48 per end-site for a reason. Since their wording > is unclear, it would help to understand the surrounding discussion > in order to make sense of it. Those architects are the ones that banned PI space in IPv6, forcing all "end sites" into a PA model where the definition is largely irrelevant. The very existence of this proposal signifies we are rejecting the IETF's plan. At most, their reasoning at the time is of historical interest. >> I think it'd be more instructive to see how ARIN itself has been >> interpreting the term to date, for both IPv4 and IPv6. If there's >> consensus that they're wrong, we can clarify the policy. > > Unfortunately, ARIN does not monitor ISP assignment activity > and the only time they would audit or review assignments is > when an ISP asks for additional addresses. This means that > ARIN has no experience whatsoever with interpreting the meaning > of end-sites. That has been done by the ISPs themselves. Not true. End sites can get IPv4 assignments under existing policy, and have been doing so since before ARIN was even formed. ARIN is also charged with reviewing every IPv6 end-site assignment by LIRs that exceeds /48. >> I'd propose that a single network with private connectivity between >> locations should count as a single "site". > > I would agree. This is a network architectural choice and > if the organization chooses this architecture then they > would get one /48. In that case, if they wish to receive > a PI allocation then it should be a single /48 to be consistent > with their architecture. That wasn't clear from your earlier messages. At least we agree on something. >> Consider that if such an org were to get PA space from one or >> more LIRs, they would get _at most_ one prefix per connection. >> They would not get a /48 per internal location. Why should PI >> policy be different? > > If their architecture was to have several connections, whether it > was one per physical location or one per regional headquarters, > the fact remains, that they have the right to choose their > network architecture. If that choice is to get 57 Internet > connections with 57 PA /48s, then they should get a PI > allocation with enough space to maintain that architecture. In theory, if they have a separate connection at each location with no internal connectivity, each location would a be a separate end-site and would have to qualify for PI space independently. Folks using such an architecture overwhelmingly single-home all but the most important locations, however. If those 57 locations all have both direct public and private connectivity, I don't see why it's essential to assign 57 separate PI blocks. If they can justify it, maybe, but you're assuming need without even asking or setting a minimum bar. > On the other hand, if their architecture is based around > 3 connections to regional headquarters which then use private > networks to the rest of the offices, then that would result > in 3 /48's, whether PA or PI. I disagree that they should get three PI /48s (or one PI /46) just because they could have gotten three PA /48s. If they can justify the space, fine, but it shouldn't be automatic. I'm not even proposing the standards for justification need to be all that high -- only that we have some. One prefix per ASN seems to be a reasonable start. >> Also, is there a compelling reason for IPv6 policy to be different in >> this respect from IPv4 policy? > > To release organisations from the scarcity-based constraints > of IPv6. I don't consider that compelling unless there are tangible benefits to the community. If a location isn't an end-site in IPv4 land, why should it be in IPv6 land? Consider that the IPv4 rules for PI assignment are pretty lax as it stands, and this proposal (even as I interpret the term "end site") is comparable. >> If the M&A targets are sufficiently independent to have their own >> ASN and own private network, I'd agree with that statement -- but at >> that point, they should qualify as a separate org for the purpose of >> PI policy and could get their own /48 (or more). No renumbering >> either way. Giving each location a /48 burns lots of routing slots >> for little real benefit. > > A /48 does not equal a routing slot. ARIN policy does not mandate all > ISPs everywhere to accept a route announcement. No, but the main point of giving out PI assignments is for use on the Internet, which today means a routing slot per assignment. If folks didn't want global routing slots, they would use ULAs. The fewer blocks an RIR policy generates, the less likely the routes to those blocks are to be filtered, and consequently the more useful the policy is. ARIN IPv6 policy (6.3.4) specifically states it is a goal "to limit the expansion of Internet routing tables." Compare to IPv4 policy (4.1.7) which states goals of "conserving scarce IPv4 address space and allowing continued use of existing Internet routing technologies." These goals seem to have very strong consensus around them, and any policy needs to be consistent with those goals. >> The fundamental problem with your model is it creates a situation >> where, after a few years of M&A, large companies will be advertising >> hundreds, if not thousands, of unaggregatable /48s per ASN. This >> _will_ create routing table problems and lead to wholesale filtering >> of PI space. > > That's why I think that PI space should be organized in such a way that > it can be aggregated by geographical proximity. I define "geographical > proximity" to mean "the nearest city over 100,000", however, it could > also be done in a less finely-grained way similar to the way truck > dispatchers have divided North America into about a dozen regions. That's an interesting model, but it's been discussed here and on NANOG several times with little forward motion. Policy needs to reflect the reality of what exists now. Ideally, it would not obstruct further development, but that is not the top priority. >> The goal should be one PI prefix per ASN. Your model starts with >> that on day one, but it will invariably get worse over time. > > You are getting your model and mine mixed together. I want to apply > science to ARIN's PI allocation algorithm in order to avoid the > worsening which you describe. Until such regions are designed, exchanges are set up, financial issues are resolved, and a non-trivial number of ISPs participate, the best we can do is to assign addresses such that regional aggregation is _possible_. We can't create policy today that _assumes_ such will come into existence. IMHO, an explosion in PI routes would not cause regional aggregation to happen; it would result in wholesale filtering. You apparently disagree. Let's leave it at that. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From Michael.Dillon at btradianz.com Wed Apr 5 06:10:33 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 5 Apr 2006 11:10:33 +0100 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text In-Reply-To: <028c01c65835$a0910f50$403816ac@ssprunk> Message-ID: > Those architects are the ones that banned PI space in IPv6, forcing all "end > sites" into a PA model where the definition is largely irrelevant. The very > existence of this proposal signifies we are rejecting the IETF's plan. At > most, their reasoning at the time is of historical interest. Yes, those architects strayed from network architecture into political and economic engineering when they assumed that the provider-centric addressing scheme would be the only supported way of building IPv6 networks. However, they did reserve 7/8ths of the IPv6 address space for alternatives so it's not as bad as it sounds. There is a saying that those who do not learn from history are doomed to repeat it. I think it is very important for all of us to be aware of what went before, not just the final outcome but some of the discussion surrounding it as well. > > Unfortunately, ARIN does not monitor ISP assignment activity > > and the only time they would audit or review assignments is > > when an ISP asks for additional addresses. This means that > > ARIN has no experience whatsoever with interpreting the meaning > > of end-sites. That has been done by the ISPs themselves. > > Not true. End sites can get IPv4 assignments under existing policy, Well, we are talking about IPv6 here... > That wasn't clear from your earlier messages. At least we agree on > something. My position is that an organization must be free to choose its own network architecture and that the PI policy should not require an organization to change the network architecture that they created with PA addresses. Under the PA rules, an organization can get a /48 per end-site, i.e. per location where they subscribe to an ISP service. PI policy should be flexible enough to allow this same scenario. > In theory, if they have a separate connection at each location with no > internal connectivity, each location would a be a separate end-site and > would have to qualify for PI space independently. Folks using such an > architecture overwhelmingly single-home all but the most important > locations, however. Organizations apply for ASes and address blocks. End-sites and subnets do not fill in ARIN applications. > If those 57 locations all have both direct public and private connectivity, > I don't see why it's essential to assign 57 separate PI blocks. If they can > justify it, maybe, but you're assuming need without even asking or setting a > minimum bar. I'm saying that the architecture is justification in and of itself. I'm saying that PI policy should not be any more restrictive than PA policy. > I'm not even proposing the standards for justification need to be all that > high -- only that we have some. One prefix per ASN seems to be a reasonable > start. It is entirely unreasonable to force a network architecture on an organization with multiple locations when we are giving individuals and small organizations much more flexibility. > > To release organisations from the scarcity-based constraints > > of IPv6. > > I don't consider that compelling unless there are tangible benefits to the > community. Tangible benefits? Well, I suppose that means money. If PI space is desirable then more people will apply for it an pay ARIN's fees. Is that good for the community? In any case, I think this talk of community is nonsense left over from the Internet of the 1980's. Some people seem to feel that by calling the network provider INDUSTRY a community, that it justifies all manner of restrictive cartel-like behavior. If there is a community that we should be concerned with, it is society in toto, and that community wants to have a resilient and reliable Internet infrastructure with full market freedoms to choose and re-choose where they buy service. The PI policy needs to meet the needs of this community even if it does have the potential to DISRUPT the way the industry currently operates. In other words, DISRUPTION is good because it is all about loosening the cartel-like constraints that were imposed because of the scarcity of IPv4 addresses and the lack of experience of policymakers 15 years ago or so. We now have 15 years of more experience, we have a huge supply of IPv6 addresses and we can correct the mistakes of the past. This means that the provider community loses a little through disruption but they stand to gain as well through continued growth for their businesses. But not under the old lock-in model. ARIN could easily issue IPv6 PI blocks from reserved blocks which are designed to be aggregated by the geographical topology. Ideally they would have separate aggregates for each city over 100,000 population but it could be done on a regional scale as well and still provide benefits to scaling of the routing table. Of course it does mean that providers who sell into that market of PI holders need to do things a little differently with interconnects and cold potato routing. But it requires no change to the technology and protocols in use. > If a location isn't an end-site in IPv4 land, why should it be in IPv6 land? Because IPv4 policy does not apply to IPv6 addressing. That is why ARIN adopted an entirely separate IPv6 policy set. End-site is an IPv6 concept with a sctrict definition. If you read the IPv4 policy you will see that it is used casually with two different meanings. Let's not confuse the two policy sets. > No, but the main point of giving out PI assignments is for use on the > Internet, which today means a routing slot per assignment. If folks didn't > want global routing slots, they would use ULAs. > > The fewer blocks an RIR policy generates, the less likely the routes to > those blocks are to be filtered, and consequently the more useful the policy > is. The fact is that we are not Soviet-style central planners. We cannot mandate anything, merely create possibilities. No matter what policy we adopt, there will always be elements out of our control such as route filtering, customer adoption and so on. That is not a reason to give up on making a good policy that creates the possibility of a freer market for network connectivity. Yes, the market could choose not to accept this freedom or the industry could throw a spanner into the works, but nevertheless, we have a duty to make the best policy that we can. > ARIN IPv6 policy (6.3.4) specifically states it is a goal "to limit the > expansion of Internet routing tables." Which is why many people have said that the PI policy needs to allocate addresses out of an identifiable aggregate. This gives providers an easy tool to limit expansion of their routing table. Some of us have pointed out how using multiple geographical aggregates could support both the limiting of routing table growth as well as the need for companies to multihome within a small geographic area, i.e. their city. > That's an interesting model, but it's been discussed here and on NANOG > several times with little forward motion. Policy needs to reflect the > reality of what exists now. Ideally, it would not obstruct further > development, but that is not the top priority. The reality that exists right now is that ARIN's own aggregation algorithm could be modified to enable this type of geo-topological aggregation. Scott Leibrand's message on PPML last month explains more about how it is workable today. http://lists.arin.net/pipermail/ppml/2006-March/005015.html > Until such regions are designed, exchanges are set up, financial issues are > resolved, and a non-trivial number of ISPs participate, the best we can do > is to assign addresses such that regional aggregation is _possible_. We > can't create policy today that _assumes_ such will come into existence. We are not central planners who can mandate that everybody must spend their money first and we will make our policy second. It is the other way around. We make our policy and then the market reacts to them. > IMHO, an explosion in PI routes would not cause regional aggregation to > happen; it would result in wholesale filtering. You apparently disagree. > Let's leave it at that. Wholesale filtering is part and parcel of the regional aggregation solution. ISPs in California SHOULD filter all detail of PI routes in New York because they only need the single regional aggregate route to send traffic to any PI end-site in New York. That is a fundamental component of this solution. --Michael Dillon From memsvcs at arin.net Wed Apr 5 16:42:55 2006 From: memsvcs at arin.net (Member Services) Date: Wed, 05 Apr 2006 16:42:55 -0400 Subject: [ppml] Reminder: Sign-up for ARIN XVII Open Policy Hour and Remote Participation Message-ID: <44342BCF.4090606@arin.net> The Open Policy Hour Sign up today to be among the first to present ideas at The Open Policy Hour, Sunday, April 9, from 4:45 - 5:30 PM (EDT). If you have a policy proposal for which you would like to receive feedback prior to submitting it to the community on the PPML, here is your opportunity. Those who sign up before the end of today will be given the first opportunity to speak. Simply send an e-mail to policy at arin.net with your name, organization, and a general description of your policy subject that you wish to present in a short presentation. Everyone is invited to attend the session and raise ideas and suggestions. You do not need to have a formal presentation in order to participate. Signing up just guarantees you the opportunity to present. Information on this and other sessions is available at: http://www.arin.net/ARIN-XVII/agenda.html Remote Participation To register for remote participation, please register through the Meeting Registration link available at http://www.arin.net/ARIN-XVII/ and choose "ARIN XVII Remote Participant" from the drop-down. Registration for this will close by 11:59 PM (EDT), April 8, 2006. Comments received during the meeting from remote participants will be moderated and presented during normal question and answer periods. ARIN will use e-mail to provide the interactive portion of the remote participation effort. All remote participants are subject to the Remote Participation Acceptable Use Policy (AUP). Additional information about remote participation, including the Remote Participation AUP, is available at: http://www.arin.net/ARIN-XVII/webcast.html We look forward to seeing you in Montreal. Meeting details are available at: http://www.arin.net/ARIN-XVII/ Please contact Member Services at memsvcs at arin.net if you have any questions. Regards, Member Services Department American Registry for Internet Numbers From memsvcs at arin.net Thu Apr 6 08:11:12 2006 From: memsvcs at arin.net (Member Services) Date: Thu, 06 Apr 2006 08:11:12 -0400 Subject: [ppml] Reminder of June 1, 2006 ip6.int deprecation Message-ID: <44350560.3060304@arin.net> ARIN wishes to remind the community that the RIRs have agreed to deprecate ip6.int on June 1, 2006. As mentioned in our March 2 announcement, in August 2005, RFC 4159 Deprecation of ip6.int was published as Best Current Practice. This RFC noted that maintenance of ip6.int is no longer required and that the Regional Internet Registries adopt a schedule for cessation of ip6.int. Further note that since 7 December 2005, ARIN no longer modifies any of the zones it administers under ip6.int. Ginny Listman Director of Engineering American Registry for Internet Numbers From narten at us.ibm.com Thu Apr 6 09:54:24 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 06 Apr 2006 09:54:24 -0400 Subject: [ppml] Definition of an (IPv6) End Site Message-ID: <200604061354.k36DsOoi016112@cichlid.raleigh.ibm.com> > We've been 'round and 'round on this before; the definition of "end > site" is obviously inadequate. If there is confusion, by definition it's inadequate! :-) > I'd propose that a single network with private connectivity between > locations should count as a single "site". This roughly correlates > with who qualifies for an ASN. If the number of locations/subnets > within that AS justifies it, they would qualify for a larger prefix > than /48. I tend to agree. Speaking as a participant in the discussions that led to the original policy (and the current wording), there was a clear intention to split the world into two groups: - those that provide internet connectivity to customers (i.e., ISPs), where the customers are not the same organization/company as the provider, and where there are many _different_ customers, and in particular not just separate "offices" in a larger businesses. - End sites, those that use the internet, get internet service from ISPs and whose core business is not providing network services to others. Obviously, there are boundary cases that are tricky. But the overall context here was that in order to get good aggregation (and reasonably bounded routing tables), you wanted ISPs to aggregate addresses for _many_ end users, i.e., customers. Doing otherwise would run the risk of (essentially) giving PI space to end users in an unscalable way. Quoting from the official (current) text: > 6.2.9. End site > > An end site is defined as an end user (subscriber) who has a > business relationship with a service provider that involves: > > 1. that service provider assigning address space to the end user > > 2. that service provider providing transit service for the end user > to other sites > > 3. that service provider carrying the end user's traffic. > > 4. that service provider advertising an aggregate prefix route that > contains the end user's assignment In my mind, the above was intended to apply to separate businesses/organizations, and not large companies that have separate IT divisions. What we didn't want is to allow end sites to simply set up shell orgnizations so that they would look like LIRs on paper. If we really wanted large end sites to get PI space, a separate policy should be developed (as is being discussed now). And, one of the other goals above is that all of the customer address ranges are covered (in the global routing tables) by a single aggregate prefix. For many large end sites, this is not what is really desired. I.e., if someone has large offices in (say) US, Europe and Japan, it may well be that each of those sites wants to be connected to the Internet via local ISPs, rather than via (say) the US location (with everything routed via the US connect point). But if this sort of local connectivity is desired, having a single aggregate that gets advertised (by giving the end site a PI assignment) doesn't happen in practice, raising the question of whether a PI assignment makes sense in the way people are claiming they are needed. Thomas From jason.schiller at mci.com Thu Apr 6 10:13:35 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 06 Apr 2006 10:13:35 -0400 (EDT) Subject: [ppml] Definition of an (IPv6) End Site In-Reply-To: <200604061354.k36DsOoi016112@cichlid.raleigh.ibm.com> Message-ID: My confusion rests not on who is an end-site, but how many end-sites that who is. Let me give you an example. Lets say I am and ISP and I have a customer that owns a chain of 100 hardware stores across the US. Each store is independently operated. Each store has a separate Internet connection through me. Each store has a single LAN that is only connected to the Internet. The stores have no interconnection at all. But there is one person at the corporate office that orders all of the T1 installs, and all bills are sent to the corporate office under a single company name. Since there is only one end-user that has a business relationship with me, would this only qualify as a single end-site, and thus all 100 locations should share a single /48? Or can I consider each separate network ate each separate location an end-site? In this case I could assign 100 /48s. What if the sites are interconnected, in that case should it be one end-site? What if the sites are interconnected, but each site has a different contact, but it is all part of the same compnay, in that case should it be one end-site? I do understand the other confusion that is going on as well, for example how is the IRS an ISP. What I want to suggest is if you are trying to tighten the language, please also consider the case above . ___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 Thu, 6 Apr 2006, Thomas Narten wrote: > Date: Thu, 06 Apr 2006 09:54:24 -0400 > From: Thomas Narten > To: ARIN PPML > Subject: [ppml] Definition of an (IPv6) End Site > > > We've been 'round and 'round on this before; the definition of "end > > site" is obviously inadequate. > > If there is confusion, by definition it's inadequate! :-) > > > I'd propose that a single network with private connectivity between > > locations should count as a single "site". This roughly correlates > > with who qualifies for an ASN. If the number of locations/subnets > > within that AS justifies it, they would qualify for a larger prefix > > than /48. > > I tend to agree. Speaking as a participant in the discussions that led > to the original policy (and the current wording), there was a clear > intention to split the world into two groups: > > - those that provide internet connectivity to customers (i.e., ISPs), > where the customers are not the same organization/company as the > provider, and where there are many _different_ customers, and in > particular not just separate "offices" in a larger businesses. > > - End sites, those that use the internet, get internet service from > ISPs and whose core business is not providing network services to > others. > > Obviously, there are boundary cases that are tricky. But the overall > context here was that in order to get good aggregation (and reasonably > bounded routing tables), you wanted ISPs to aggregate addresses for > _many_ end users, i.e., customers. Doing otherwise would run the risk > of (essentially) giving PI space to end users in an unscalable way. > > Quoting from the official (current) text: > > > 6.2.9. End site > > > > An end site is defined as an end user (subscriber) who has a > > business relationship with a service provider that involves: > > > > 1. that service provider assigning address space to the end user > > > > 2. that service provider providing transit service for the end user > > to other sites > > > > 3. that service provider carrying the end user's traffic. > > > > 4. that service provider advertising an aggregate prefix route that > > contains the end user's assignment > > In my mind, the above was intended to apply to separate > businesses/organizations, and not large companies that have separate > IT divisions. What we didn't want is to allow end sites to simply set > up shell orgnizations so that they would look like LIRs on paper. > > If we really wanted large end sites to get PI space, a separate policy > should be developed (as is being discussed now). > > And, one of the other goals above is that all of the customer address > ranges are covered (in the global routing tables) by a single > aggregate prefix. > > For many large end sites, this is not what is really desired. I.e., if > someone has large offices in (say) US, Europe and Japan, it may well > be that each of those sites wants to be connected to the Internet via > local ISPs, rather than via (say) the US location (with everything > routed via the US connect point). But if this sort of local > connectivity is desired, having a single aggregate that gets > advertised (by giving the end site a PI assignment) doesn't happen in > practice, raising the question of whether a PI assignment makes sense > in the way people are claiming they are needed. > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From owen at delong.com Thu Apr 6 10:50:37 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 06 Apr 2006 07:50:37 -0700 Subject: [ppml] Definition of an (IPv6) End Site In-Reply-To: <200604061354.k36DsOoi016112@cichlid.raleigh.ibm.com> References: <200604061354.k36DsOoi016112@cichlid.raleigh.ibm.com> Message-ID: <873EFD9914C8255F06264D07@imac-en0.delong.sj.ca.us> I do think it is important to have both distinctions to some extent. Afterall, an organization which is not an LIR is not the same as an organization which does not qualify as an LIR. I do not believe we should issue end-user assignments to organizations which qualify as LIRs in IPv6. I also think there is some work to be done in clarifying the qualification of an LIR. I have heard at least two distinct versions of what does and does not qualify as an LIR. In one version, I've been told that ARIN staff would not grant LIR status to Megacorp. IT based on its plan to delegate addresses to 200+ Megacorp. business units and/or departments. In another version, I have been told that ARIN staff would interpret this as a valid request. I don't honestly know which is currently true and/or whether it has ever changed. Further, as I read the NRPM, it should be considered a valid request, but, the NRPM does not make clear what type of relationship or non-relationship is required in order to qualify as "other organization". If I were to put on my ARIN defined terms only blinders, then, an Organization would be any entity which has an ARIN ORG-ID, and, "other organization" would then refer to any entity with an ORG-ID different from my own. Since anyone can easily create as many ORG-IDs as they need, that doesn't seem to me to be a very useful definition in this context. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From billd at cait.wustl.edu Thu Apr 6 11:00:17 2006 From: billd at cait.wustl.edu (billd at cait.wustl.edu) Date: Thu, 6 Apr 2006 10:00:17 -0500 Subject: [ppml] Definition of an (IPv6) End Site Message-ID: As I said earlier.... My definition would be..... I would suggest that it implies that the organization's network is not used to provide for-fee transit to other networks not under their own management. In addition, depending upon architecture and communication strategy, an organization might choose to deem a particular element of it's distributed network a separate end-site, or consider the entire distributed infrastructure a single end-site. In such case, the hardware chain and you as an ISP would perhaps jointly figure out what the best definition is for each independent, or some aggregate....it's a business and architectural issue. But, I believe that if each individual HW store is to be deemed and end-site, then they may be restricted by a policy hurdle to acquire PI space. Bill Darte > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Jason Schiller (schiller at uu.net) > Sent: Thursday, April 06, 2006 9:14 AM > To: Thomas Narten > Cc: ARIN PPML > Subject: Re: [ppml] Definition of an (IPv6) End Site > > > My confusion rests not on who is an end-site, but how many > end-sites that who is. > > Let me give you an example. Lets say I am and ISP and I have > a customer that owns a chain of 100 hardware stores across > the US. Each store is independently operated. Each store > has a separate Internet connection through me. Each store > has a single LAN that is only connected to the Internet. The > stores have no interconnection at all. > > But there is one person at the corporate office that orders > all of the T1 installs, and all bills are sent to the > corporate office under a single company name. > > Since there is only one end-user that has a business > relationship with me, would this only qualify as a single > end-site, and thus all 100 locations should share a single > /48? Or can I consider each separate network ate each > separate location an end-site? In this case I could assign 100 /48s. > > What if the sites are interconnected, in that case should it > be one end-site? > > What if the sites are interconnected, but each site has a > different contact, but it is all part of the same compnay, in > that case should it be one end-site? > > > I do understand the other confusion that is going on as well, > for example how is the IRS an ISP. > > What I want to suggest is if you are trying to tighten the > language, please also consider the case above . > > ___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 Thu, 6 Apr 2006, Thomas Narten wrote: > > > Date: Thu, 06 Apr 2006 09:54:24 -0400 > > From: Thomas Narten > > To: ARIN PPML > > Subject: [ppml] Definition of an (IPv6) End Site > > > > > We've been 'round and 'round on this before; the > definition of "end > > > site" is obviously inadequate. > > > > If there is confusion, by definition it's inadequate! :-) > > > > > I'd propose that a single network with private > connectivity between > > > locations should count as a single "site". This roughly > correlates > > > with who qualifies for an ASN. If the number of > locations/subnets > > > within that AS justifies it, they would qualify for a > larger prefix > > > than /48. > > > > I tend to agree. Speaking as a participant in the > discussions that led > > to the original policy (and the current wording), there was a clear > > intention to split the world into two groups: > > > > - those that provide internet connectivity to customers > (i.e., ISPs), > > where the customers are not the same organization/company as the > > provider, and where there are many _different_ customers, and in > > particular not just separate "offices" in a larger businesses. > > > > - End sites, those that use the internet, get internet service from > > ISPs and whose core business is not providing network services to > > others. > > > > Obviously, there are boundary cases that are tricky. But > the overall > > context here was that in order to get good aggregation (and > reasonably > > bounded routing tables), you wanted ISPs to aggregate addresses for > > _many_ end users, i.e., customers. Doing otherwise would > run the risk > > of (essentially) giving PI space to end users in an unscalable way. > > > > Quoting from the official (current) text: > > > > > 6.2.9. End site > > > > > > An end site is defined as an end user (subscriber) who has a > > > business relationship with a service provider that involves: > > > > > > 1. that service provider assigning address space to the end user > > > > > > 2. that service provider providing transit service for > the end user > > > to other sites > > > > > > 3. that service provider carrying the end user's traffic. > > > > > > 4. that service provider advertising an aggregate prefix > route that > > > contains the end user's assignment > > > > In my mind, the above was intended to apply to separate > > businesses/organizations, and not large companies that have > separate > > IT divisions. What we didn't want is to allow end sites to > simply set > > up shell orgnizations so that they would look like LIRs on paper. > > > > If we really wanted large end sites to get PI space, a > separate policy > > should be developed (as is being discussed now). > > > > And, one of the other goals above is that all of the > customer address > > ranges are covered (in the global routing tables) by a single > > aggregate prefix. > > > > For many large end sites, this is not what is really > desired. I.e., if > > someone has large offices in (say) US, Europe and Japan, it > may well > > be that each of those sites wants to be connected to the > Internet via > > local ISPs, rather than via (say) the US location (with everything > > routed via the US connect point). But if this sort of local > > connectivity is desired, having a single aggregate that gets > > advertised (by giving the end site a PI assignment) doesn't > happen in > > practice, raising the question of whether a PI assignment > makes sense > > in the way people are claiming they are needed. > > > > Thomas > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From Michael.Dillon at btradianz.com Thu Apr 6 11:19:49 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 6 Apr 2006 16:19:49 +0100 Subject: [ppml] Definition of an (IPv6) End Site In-Reply-To: Message-ID: > Since there is only one end-user that has a business relationship with me, > would this only qualify as a single end-site, and thus all 100 locations > should share a single /48? Or can I consider each separate network ate > each separate location an end-site? In this case I could assign 100 /48s. The current policy says that the end-site definition is based on the BUSINESS RELATIONSHIP. Therefore, if the company chooses to have one unified business relationship with you, they get one /48. If they choose to maintain 100 business relationships with you and have 100 bills sent to the 100 separate locations, then they get 100 /48 blocks. In other words, the current policy allows the customer to choose. IMHO, this is a good thing. It is not our business to tell people how to structure their businesses or how to architect their networks. Now, we could change the policy to mandate how they structure their business but I would expect that such a move would lead to lawsuits when some of those businesses realize that the mandated business structure leads to financial losses. 10 years ago, we could make ARIN policies the way we wanted them to be under cover of scarcity constraints in IPv4. But now those constraints have gone away, the Internet has grown up and become the mission critical communications structure for everyone. We no longer are free to make policies the way we want to in IPv6. We must now balance the interests of all stakeholders and make wise policies, even when that means that our personal favorite set of stakeholders does not get all that they want. IPv6 does not have the same constraints as IPv6 and therefore does not provide ARIN and its policymakers with the same protection from scrutiny that was available with IPv4. --Michael Dillon --Michael Dillon From jason.schiller at mci.com Thu Apr 6 11:52:06 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 06 Apr 2006 11:52:06 -0400 (EDT) Subject: [ppml] Definition of an (IPv6) End Site In-Reply-To: Message-ID: Michael, Let my try to ask the questions a different way. First off I don't disagree with you, giving the customer flexibility in what their business relationship is or how they architect their network is a good thing. > In other words, the current policy allows the customer > to choose. IMHO, this is a good thing. It is not our > business to tell people how to structure their businesses > or how to architect their networks. Is it acceptable Under current ARIN policy (should it be acceptable under future ARIN policy), if the hardware store wants each of its separate non-interconnected locations to be a different end-site with its own /48, but have the business relationship be through a single point of contact? If the answer to this question is no, then ARIN policy is mandating how they structure their business relationship given a particular prefered network architecture or vice versa. ___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 Thu, 6 Apr 2006 Michael.Dillon at btradianz.com wrote: > Date: Thu, 06 Apr 2006 16:19:49 +0100 > From: Michael.Dillon at btradianz.com > To: ppml at arin.net > Subject: Re: [ppml] Definition of an (IPv6) End Site > > > Since there is only one end-user that has a business relationship with > me, > > would this only qualify as a single end-site, and thus all 100 locations > > should share a single /48? Or can I consider each separate network ate > > each separate location an end-site? In this case I could assign 100 > /48s. > > The current policy says that the end-site definition is > based on the BUSINESS RELATIONSHIP. Therefore, if the > company chooses to have one unified business relationship > with you, they get one /48. If they choose to maintain > 100 business relationships with you and have 100 bills > sent to the 100 separate locations, then they get 100 > /48 blocks. > > In other words, the current policy allows the customer > to choose. IMHO, this is a good thing. It is not our > business to tell people how to structure their businesses > or how to architect their networks. > > Now, we could change the policy to mandate how they structure > their business but I would expect that such a move would > lead to lawsuits when some of those businesses realize that > the mandated business structure leads to financial losses. > > 10 years ago, we could make ARIN policies the way we > wanted them to be under cover of scarcity constraints > in IPv4. But now those constraints have gone away, the > Internet has grown up and become the mission critical > communications structure for everyone. We no longer are > free to make policies the way we want to in IPv6. We must > now balance the interests of all stakeholders and make > wise policies, even when that means that our personal > favorite set of stakeholders does not get all that they > want. IPv6 does not have the same constraints as IPv6 and > therefore does not provide ARIN and its policymakers with > the same protection from scrutiny that was available with > IPv4. > > --Michael Dillon > > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From jdhoule at att.com Thu Apr 6 12:21:17 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Thu, 6 Apr 2006 11:21:17 -0500 Subject: [ppml] Definition of an (IPv6) End Site In-Reply-To: Message-ID: Folks: I don't exactly buy into the BUSINESS RELATIONSHIP driving what a site is. I would think that each of the 100 stores getting it's own /48 is one of potentially many valid interpretation of what is a site. This interpretation makes more or less sense depending on other things, like: Is there a private network (virtual or not) between store, are these franchised, etc. Do we all need to buy into the same interpretation under all circumstances? Or do we just need to agree that a given interpretation is a valid one? Joe Houle -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Jason Schiller (schiller at uu.net) Sent: Thursday, April 06, 2006 11:52 AM To: Michael.Dillon at btradianz.com Cc: ppml at arin.net Subject: Re: [ppml] Definition of an (IPv6) End Site Michael, Let my try to ask the questions a different way. First off I don't disagree with you, giving the customer flexibility in what their business relationship is or how they architect their network is a good thing. > In other words, the current policy allows the customer > to choose. IMHO, this is a good thing. It is not our > business to tell people how to structure their businesses > or how to architect their networks. Is it acceptable Under current ARIN policy (should it be acceptable under future ARIN policy), if the hardware store wants each of its separate non-interconnected locations to be a different end-site with its own /48, but have the business relationship be through a single point of contact? If the answer to this question is no, then ARIN policy is mandating how they structure their business relationship given a particular prefered network architecture or vice versa. ___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 Thu, 6 Apr 2006 Michael.Dillon at btradianz.com wrote: > Date: Thu, 06 Apr 2006 16:19:49 +0100 > From: Michael.Dillon at btradianz.com > To: ppml at arin.net > Subject: Re: [ppml] Definition of an (IPv6) End Site > > > Since there is only one end-user that has a business relationship with > me, > > would this only qualify as a single end-site, and thus all 100 locations > > should share a single /48? Or can I consider each separate network ate > > each separate location an end-site? In this case I could assign 100 > /48s. > > The current policy says that the end-site definition is > based on the BUSINESS RELATIONSHIP. Therefore, if the > company chooses to have one unified business relationship > with you, they get one /48. If they choose to maintain > 100 business relationships with you and have 100 bills > sent to the 100 separate locations, then they get 100 > /48 blocks. > > In other words, the current policy allows the customer > to choose. IMHO, this is a good thing. It is not our > business to tell people how to structure their businesses > or how to architect their networks. > > Now, we could change the policy to mandate how they structure > their business but I would expect that such a move would > lead to lawsuits when some of those businesses realize that > the mandated business structure leads to financial losses. > > 10 years ago, we could make ARIN policies the way we > wanted them to be under cover of scarcity constraints > in IPv4. But now those constraints have gone away, the > Internet has grown up and become the mission critical > communications structure for everyone. We no longer are > free to make policies the way we want to in IPv6. We must > now balance the interests of all stakeholders and make > wise policies, even when that means that our personal > favorite set of stakeholders does not get all that they > want. IPv6 does not have the same constraints as IPv6 and > therefore does not provide ARIN and its policymakers with > the same protection from scrutiny that was available with > IPv4. > > --Michael Dillon > > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Thu Apr 6 12:37:14 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 6 Apr 2006 11:37:14 -0500 Subject: [ppml] Definition of an (IPv6) End Site References: Message-ID: <021001c65998$5dbf3170$3b3816ac@ssprunk> Thus spake "Jason Schiller (schiller at uu.net)" > My confusion rests not on who is an end-site, but how many end-sites > that who is. > > Let me give you an example. Lets say I am and ISP and I have a customer > that owns a chain of 100 hardware stores across the US. Each store is > independently operated. Each store has a separate Internet connection > through me. Each store has a single LAN that is only connected to the > Internet. The stores have no interconnection at all. > > But there is one person at the corporate office that orders all of the > T1 installs, and all bills are sent to the corporate office under a single > company name. > > Since there is only one end-user that has a business relationship with me, > would this only qualify as a single end-site, and thus all 100 locations > should share a single /48? Or can I consider each separate network ate > each separate location an end-site? In this case I could assign 100 /48s. Assuming you're talking PA space for this case, there's no harm in giving each location a separate /48. If they planned on interconnecting at a later date, I'd suggest they share a single /48. However, as long as we're talking PA space, the definition of "end site" can be up to the LIR. > What if the sites are interconnected, in that case should it be one > end-site? IMHO, yes. > What if the sites are interconnected, but each site has a different > contact, but it is all part of the same compnay, in that case should it be > one end-site? Yes. Subsidiaries should only count as "other organizations" if they operate an autonomous network with distinct policies and requirements. Shell companies, business units, and "internal service providers" do not qualify merely because someone draws cute diagrams in Visio. A wholly- or partially-owned subsidiary is the interesting case. If someone showed me contracts for service, a flow of invoices and payments, etc. I'd probably agree they're separate orgs. If the two had no private interconnection (e.g. exchanged email over the Internet), I'd agree. If they shared the same network but had internal "charge-backs", I'd disagree. There's a lot of gray in between, however. > I do understand the other confusion that is going on as well, for example > how is the IRS an ISP. IMHO, letting the IRS claim to be an LIR was a clear violation of policy, but given that there was no PI policy available, what else was ARIN to do when presented with an otherwise reasonable request? (Not to mention the IRS is not a group you want mad at you...) Ditto for the various other state and federal orgs that have managed to get themselves accepted as LIRs. However, there's a relatively small number of those, so if it were just them it'd not be a dire emergency. However, that same hole has apparently been abused by enterprises as well, and there's a _lot_ of private businesses out there. Is Cisco really a LIR? Is IBM? Only the biggest companies are doing it so far, but those are also the folks that will be telling _their customers_ to do the same as a "best practice", complete with slideware on how to do it. > What I want to suggest is if you are trying to tighten the language, > please also consider the case above . I believe that's exactly what we're trying to address. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From Lee.Howard at stanleyassociates.com Thu Apr 6 13:44:54 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 6 Apr 2006 13:44:54 -0400 Subject: [ppml] Summary of IPv6 assignment proposals Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB401BD9DA1@CL-S-EX-1.stanleyassociates.com> According to http://www.arin.net/policy/proposals/proposal_archive.html, there are three proposals related to IPv6 assignments for non-LIRs which are currently under consideration. In order to adopt a policy, we have to have consensus. Roughly: Proposal 2005-1 would say: if you're not an IPv6 LIR, and qualify for an IPv4 direct assignment, you can have a /48 (or larger, if needed). Proposal 2005-8 would say: if you're not an LIR, get your IPv6 from your LIR (and recommendations on what the LIR should assign). Proposal 2006-4 would say: if you're not an LIR, and you're multihomed, and have used 90% of a directly-assigned IPv4 /19, you can have a /48. If you use 50% of your /64s or /48s, you can have then next bit. If you need more than a /44, you're automatically an LIR. The question for you, as a member of the public [1], is which of these proposals ARIN should adopt, if any. If you like the direction of a proposal, but don't like some part of it, consider whether your concern means you withhold support, or if it should be adopted and modified later. Then, if you haven't already said it, email your response to this list, or to the AC member of your choice [2], or at least speak up at the Public Policy Meeting [3]. The ARIN Advisory Council will judge consensus based on list activity and comments at the meeting. This message is not sponsored by ARIN. I just can't tell who is in favor of what. Lee [1] You don't have to be a member of ARIN. [2] Email addresses at http://www.arin.net/about_us/ac.html [3] Including remote particpation, registration required, http://www.arin.net/ARIN-XVII/webcast.html From memsvcs at arin.net Thu Apr 6 13:50:28 2006 From: memsvcs at arin.net (Member Services) Date: Thu, 06 Apr 2006 13:50:28 -0400 Subject: [ppml] Proposed Policy: Bulk WHOIS agreement expiration clarification Message-ID: <443554E4.6020903@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The 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. The AC review will be conducted at the next regularly scheduled meeting of the AC that occurs after the proposal is posted to PPML. Since this proposal was received within 10 days of the next scheduled meeting of the ARIN Advisory Council, the review period will be extended to the regularly scheduled meeting that occurs after the upcoming meeting. This proposal will not be on the agenda for the upcoming ARIN XVII Public Policy 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: Bulk WHOIS agreement expiration clarification Author: Bill Woodcock Proposal Version: 1.0 Proposal type: Modify Policy term: Permanent Policy statement: Text added to the end of "3.1. Bulk Copies of ARIN's WHOIS": If no term of validity or expiration date is included in the policy or AUP, it shall be deemed valid upon acceptance by ARIN and shall conclude after thirty days notice by ARIN, immediately upon cancellation by the other signatory, or immediately upon a violation of its terms. If an expiration date is included, ARIN shall provide thirty days notice prior to the expiration of an AUP agreement, in order that the data recipient shall have the opportunity to receive uninterrupted service. Rationale: Presently, there is no expiration date specified in either the AUP agreement nor in the policy. ARIN whois data recipients receive an FTP login to an ARIN server, which unexpectedly stops working one day, breaking lots of scripts, causing gaps in datasets, and causing people to waste a lot of time debugging, only to find that the login has been deactivated with no forewarning. If ARIN staff are going to arbitrarily decide to "expire" an agreement which has no defined expiration, doing so unilaterally and without notice is an extraordinarily bad idea. Let me just say that I think it's really pitiful that we should need to use the policy process to micromanage operations at this level. But believe me, I wouldn't be wasting my time writing something this trivial if it weren't necessary to solve an actual problem. Timetable for implementation: Immediate. Meeting presenter: Bill Woodcock From sleibrand at internap.com Thu Apr 6 14:00:24 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 6 Apr 2006 14:00:24 -0400 (EDT) Subject: [ppml] Summary of IPv6 assignment proposals In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401BD9DA1@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB401BD9DA1@CL-S-EX-1.stanleyassociates.com> Message-ID: Howard, As I've stated earlier, I support 2005-1 as my first choice. I would also support 2006-4 if 2005-1 doesn't achieve consensus. I disagree with your characterization of 2005-8. As I read it, 2005-8 is orthogonal to PI proposals, and simply "is intended to make the default assignment size a /56 in the vast number of cases where a /48 seems profligate." As such, I support 2005-8 *in addition to* (not instead of) 2005-1 or 2006-4. -Scott On 04/06/06 at 1:44pm -0400, Howard, W. Lee According to http://www.arin.net/policy/proposals/proposal_archive.html, > there > are three proposals related to IPv6 assignments for non-LIRs which are > currently under consideration. In order to adopt a policy, we have to > have > consensus. Roughly: > > Proposal 2005-1 would say: if you're not an IPv6 LIR, and qualify for an > IPv4 > direct assignment, you can have a /48 (or larger, if needed). > > Proposal 2005-8 would say: if you're not an LIR, get your IPv6 from your > LIR > (and recommendations on what the LIR should assign). > > Proposal 2006-4 would say: if you're not an LIR, and you're multihomed, > and > have used 90% of a directly-assigned IPv4 /19, you can have a /48. If > you > use 50% of your /64s or /48s, you can have then next bit. If you need > more > than a /44, you're automatically an LIR. > > The question for you, as a member of the public [1], is which of these > proposals ARIN should adopt, if any. If you like the direction of a > proposal, > but don't like some part of it, consider whether your concern means you > withhold support, or if it should be adopted and modified later. Then, > if > you haven't already said it, email your response to this list, or to the > AC > member of your choice [2], or at least speak up at the Public Policy > Meeting [3]. The ARIN Advisory Council will judge consensus based on > list > activity and comments at the meeting. > > > This message is not sponsored by ARIN. I just can't tell who is in > favor of what. > > Lee > > > [1] You don't have to be a member of ARIN. > [2] Email addresses at http://www.arin.net/about_us/ac.html > [3] Including remote particpation, registration required, > http://www.arin.net/ARIN-XVII/webcast.html > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From owen at delong.com Thu Apr 6 14:43:11 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 06 Apr 2006 11:43:11 -0700 Subject: [ppml] Summary of IPv6 assignment proposals In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401BD9DA1@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB401BD9DA1@CL-S-EX-1.stanleyassoc iates.com> Message-ID: Lee, I'm pretty sure you know I support 2005-1, but, thanks for your message. I think it's a reasonable summary of the proposals and provides a clear opportunity for some good public comment before and during the meeting. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Apr 6 14:45:09 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 06 Apr 2006 11:45:09 -0700 Subject: [ppml] Proposed Policy: Bulk WHOIS agreement expiration clarification In-Reply-To: <443554E4.6020903@arin.net> References: <443554E4.6020903@arin.net> Message-ID: <624CF0982DBA6604B91227AF@imac-en0.delong.sj.ca.us> In general, I like this. However, I would change the violation claus to ... or upon notice from ARIN to the other party that ARIN believes the terms were violated... With the current language, the determination of a violation is left far too ambiguous for my tastes. Owen --On April 6, 2006 1:50:28 PM -0400 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. > > The AC review will be conducted at the next regularly scheduled meeting > of the AC that occurs after the proposal is posted to PPML. > > Since this proposal was received within 10 days of the next scheduled > meeting of the ARIN Advisory Council, the review period will be extended > to the regularly scheduled meeting that occurs after the upcoming meeting. > > This proposal will not be on the agenda for the upcoming ARIN XVII > Public Policy 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: Bulk WHOIS agreement expiration clarification > > Author: Bill Woodcock > > Proposal Version: 1.0 > > Proposal type: Modify > > Policy term: Permanent > > Policy statement: > > Text added to the end of "3.1. Bulk Copies of ARIN's WHOIS": > > If no term of validity or expiration date is included in the policy or > AUP, it shall be deemed valid upon acceptance by ARIN and shall conclude > after thirty days notice by ARIN, immediately upon cancellation by the > other signatory, or immediately upon a violation of its terms. If an > expiration date is included, ARIN shall provide thirty days notice prior > to the expiration of an AUP agreement, in order that the data recipient > shall have the opportunity to receive uninterrupted service. > > Rationale: > > Presently, there is no expiration date specified in either the AUP > agreement nor in the policy. ARIN whois data recipients receive an FTP > login to an ARIN server, which unexpectedly stops working one day, > breaking lots of scripts, causing gaps in datasets, and causing people > to waste a lot of time debugging, only to find that the login has been > deactivated with no forewarning. If ARIN staff are going to arbitrarily > decide to "expire" an agreement which has no defined expiration, doing > so unilaterally and without notice is an extraordinarily bad idea. > > Let me just say that I think it's really pitiful that we should need to > use the policy process to micromanage operations at this level. But > believe me, I wouldn't be wasting my time writing something this trivial > if it weren't necessary to solve an actual problem. > > Timetable for implementation: Immediate. > > Meeting presenter: Bill Woodcock > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From narten at us.ibm.com Thu Apr 6 15:47:07 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 06 Apr 2006 15:47:07 -0400 Subject: [ppml] PI Policy 2005-01/2006-04: issues Message-ID: <200604061947.k36Jl7md005897@cichlid.raleigh.ibm.com> On Monday afternoon, we will be discussing the two PI for end site proposals (2005-01 and 2006-04) at the ARIN meeting. The hope is that during the meeting, we can reach agreement on one proposal (possibly with modifications) to move forward. On the other hand, I have the fear that the discussion will fracture, with support split between the two proposals, a resulting deadlock, and then no clear way forward. Let's try to avoid that outcome. I will be posting several follouwp messages, each one focussed on comparing key differences of the two proposals. The aim then is to have discussion on these differences (individually) in order to find common ground on the key elements. Having discussion of the form "I like proposal X better" aren't helpful in this context. Discussion about "I support aspect Y of proposal X, and here is the reason why", or "I don't think either proposal gets this part exactly right, and here is what I'd propose instead" would be much more constructive. Thomas From narten at us.ibm.com Thu Apr 6 15:48:26 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 06 Apr 2006 15:48:26 -0400 Subject: [ppml] PI Policy 2005-01/2006-04: Identifying/filtering prefixes Message-ID: <200604061948.k36JmQFM005905@cichlid.raleigh.ibm.com> Issue/topic: is it desirable/necessary to be able to identify PI prefixes for filtering purposes? If so, how will this be achieved? 2005-01: Nothing explicitely stated. no recommendation to assign PI blocks out of a well-known prefix. 2006-04: Proposal says: > Direct Assignments shall be allocated from a separate super-block > to allow for LIRs to filter. Thomas From narten at us.ibm.com Thu Apr 6 15:48:45 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 06 Apr 2006 15:48:45 -0400 Subject: [ppml] PI Policy 2005-01/2006-04: On mininum assignment size Message-ID: <200604061948.k36Jmj9i005913@cichlid.raleigh.ibm.com> 2005-01: minimum of /48, larger possible, when justified 2006-04: /48 out of reserved /44. Multiple ASN holders get (larger) aggregate assignment that allows for a /48 per ASN. Thomas From narten at us.ibm.com Thu Apr 6 15:50:17 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 06 Apr 2006 15:50:17 -0400 Subject: [ppml] PI Policy 2005-01/2006-04: "reservation" for future growth Message-ID: <200604061950.k36JoHxv005924@cichlid.raleigh.ibm.com> On Arin "holding in reserve" address space for future requests from same assignee: 2005-01: Not specified. Specifically, the proposal says: > When possible assignments will be made from an adjacent address block. 2006-04: RIR holds /44 in reserve. Proposal says: > Organizations that meet the direct end site assignment criteria are > eligible to receive a direct assignment of /48 out of a reserved /44. Thomas From narten at us.ibm.com Thu Apr 6 15:51:44 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 06 Apr 2006 15:51:44 -0400 Subject: [ppml] PI Policy 2005-01/2006-04: On maximum assigned prefix Message-ID: <200604061951.k36JpiuX005935@cichlid.raleigh.ibm.com> On maximum size of assigned prefix: 2005-01: unspecified (and unclear whether and how much space RIR is expected to hold in reserve in anticipation of future growth) 2006-04: max of /44. Thomas From narten at us.ibm.com Thu Apr 6 15:52:36 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 06 Apr 2006 15:52:36 -0400 Subject: [ppml] PI Policy 2005-01/2006-04: criteria for obtaining additional space Message-ID: <200604061952.k36Jqa8G005943@cichlid.raleigh.ibm.com> On justification for more address space than the default: 2005-01: No specific criteria specified. I.e.: > Organizations requesting a larger assignment must provide > documentation justifying the need for additional subnets. 2006-04: Proposal says: > Organization's assignment size may be increased to the next larger > prefix (to a maximum of /44) when the organization demonstrates any of > the following criteria: > > 1. 50% of the assigned /64 subnets are utilized > 2. 50% of the /48 subnets are assigned and utilized to unique > ASN assignments > > Organizations which request and can justify assignments larger than /44 > shall qualify as LIRs and must make application for an allocation under > policies applicable to an LIR, except that they shall be exempted from > the requirement to assign addresses to other organizations. Thomas From narten at us.ibm.com Thu Apr 6 15:54:05 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 06 Apr 2006 15:54:05 -0400 Subject: [ppml] PI Policy 2005-01/2006-04: Eligibility Message-ID: <200604061954.k36Js5fB005957@cichlid.raleigh.ibm.com> On qualifications for obtaining a PI assignment: 2005-01: Proposal says: > a) not be an IPv6 LIR; and > > b) Qualify for an IPv4 assignment or allocation from ARIN under the > IPv4 policy currently in effect. Discussion/commentary: in practice, this appears to mean: line b) above is presumably intended to be restricted to 4.3 "End-users - Assignments to end-users", but that isn't clearly stated, so others may be eligible than desired/intended. The current IPv4 criteria states: > 4.3.2. Minimum assignment > > 4.3.2.1 Single Connection > > The minimum block of IP address space assigned by ARIN to > end-users is a /20. If assignments smaller than /20 are needed, > end-users should contact their upstream provider. > > 4.3.2.2 Multihomed Connection > > For end-users who demonstrate an intent to announce the requested > space in a multihomed fashion, the minimum block of IP address > space assigned is a /22. If assignments smaller than a /22 are > needed, multihomed end-users should contact their upstream > providers. When prefixes are assigned which are longer than /20, > they will be from a block reserved for that purpose. 2006-04: > To qualify for a direct end site assignment, an organization must meet > all of the following criteria: > > 1. not be an LIR; > 2. be an end site; > 3. be currently multihomed using IPv4; > 4. have a direct assignment from ARIN of at least a IPv4 /19 and can > show the current utilization of 80% of an IPv4 /19 equivalent. Thomas From tme at multicasttech.com Thu Apr 6 16:01:02 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 6 Apr 2006 16:01:02 -0400 Subject: [ppml] PI Policy 2005-01/2006-04: On mininum assignment size In-Reply-To: <200604061948.k36Jmj9i005913@cichlid.raleigh.ibm.com> References: <200604061948.k36Jmj9i005913@cichlid.raleigh.ibm.com> Message-ID: <9E6DDD4E-F522-4071-9C76-B6B6DBB8BC20@multicasttech.com> In general, I am in favor of 2005-01 (but support 2006-04 over doing nothing). However, in this particular feature, I think that 2006-04 has the better idea. Regards Marshall Eubanks On Apr 6, 2006, at 3:48 PM, Thomas Narten wrote: > 2005-01: > > minimum of /48, larger possible, when justified > > 2006-04: > > /48 out of reserved /44. > > Multiple ASN holders get (larger) aggregate assignment that allows for > a /48 per ASN. > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From arin-member at quadrix.com Thu Apr 6 16:05:07 2006 From: arin-member at quadrix.com (Bill Van Emburg) Date: Thu, 06 Apr 2006 15:05:07 -0500 Subject: [ppml] PPML Digest, Vol 10, Issue 10 In-Reply-To: References: Message-ID: <44357473.1030603@quadrix.com> I am in favor of 2005-1. I think that this is the best policy, and the simplest that will work. I think 2006-4 is a little bit more restrictive in terms of receiving an initial allocation, and I think that is not a great idea. However, it's better than the current "use 200 networks" requirement (or whatever that number is...). I do not support 2005-8, regardless of whether Scott's interpretation or Lee's interpretation is correct. I don't think we need to switch to /56 as default at this time, and I don't think IPv6 end users should be restricted to getting their IPs from an LIR. Most importantly, I think we need to make it very explicit that there is no "permanent" IPv6 assignment. ARIN *must* retain the right to reclaim IPv6 addresses at a later date, if the user can not justify it under the then-current policy. I also think that allocations should be required to be returned to ARIN or re-justified when another organization takes over the IP space. IPs are not an asset to be bought and sold privately; they are a public trust. -Bill Van Emburg Quadrix Solutions, Inc. > ------------------------------ > > Message: 5 > Date: Thu, 6 Apr 2006 14:00:24 -0400 (EDT) > From: Scott Leibrand > Subject: Re: [ppml] Summary of IPv6 assignment proposals > To: "Howard, W. Lee" > Cc: ppml at arin.net > Message-ID: > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Howard, > > As I've stated earlier, I support 2005-1 as my first choice. I would also > support 2006-4 if 2005-1 doesn't achieve consensus. > > I disagree with your characterization of 2005-8. As I read it, 2005-8 is > orthogonal to PI proposals, and simply "is intended to make the default > assignment size a /56 in the vast number of cases where a /48 seems > profligate." As such, I support 2005-8 *in addition to* (not instead of) > 2005-1 or 2006-4. > > -Scott > > On 04/06/06 at 1:44pm -0400, Howard, W. Lee >> According to http://www.arin.net/policy/proposals/proposal_archive.html, >> there >> are three proposals related to IPv6 assignments for non-LIRs which are >> currently under consideration. In order to adopt a policy, we have to >> have >> consensus. Roughly: >> >> Proposal 2005-1 would say: if you're not an IPv6 LIR, and qualify for an >> IPv4 >> direct assignment, you can have a /48 (or larger, if needed). >> >> Proposal 2005-8 would say: if you're not an LIR, get your IPv6 from your >> LIR >> (and recommendations on what the LIR should assign). >> >> Proposal 2006-4 would say: if you're not an LIR, and you're multihomed, >> and >> have used 90% of a directly-assigned IPv4 /19, you can have a /48. If >> you >> use 50% of your /64s or /48s, you can have then next bit. If you need >> more >> than a /44, you're automatically an LIR. >> >> The question for you, as a member of the public [1], is which of these >> proposals ARIN should adopt, if any. If you like the direction of a >> proposal, >> but don't like some part of it, consider whether your concern means you >> withhold support, or if it should be adopted and modified later. Then, >> if >> you haven't already said it, email your response to this list, or to the >> AC >> member of your choice [2], or at least speak up at the Public Policy >> Meeting [3]. The ARIN Advisory Council will judge consensus based on >> list >> activity and comments at the meeting. >> >> >> This message is not sponsored by ARIN. I just can't tell who is in >> favor of what. >> >> Lee >> >> >> [1] You don't have to be a member of ARIN. >> [2] Email addresses at http://www.arin.net/about_us/ac.html >> [3] Including remote particpation, registration required, >> http://www.arin.net/ARIN-XVII/webcast.html >> _______________________________________________ From tme at multicasttech.com Thu Apr 6 16:09:02 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 6 Apr 2006 16:09:02 -0400 Subject: [ppml] PI Policy 2005-01/2006-04: Eligibility In-Reply-To: <200604061954.k36Js5fB005957@cichlid.raleigh.ibm.com> References: <200604061954.k36Js5fB005957@cichlid.raleigh.ibm.com> Message-ID: On Apr 6, 2006, at 3:54 PM, Thomas Narten wrote: > On qualifications for obtaining a PI assignment: > > 2005-01: > > Proposal says: > >> a) not be an IPv6 LIR; and >> >> b) Qualify for an IPv4 assignment or allocation from ARIN under the >> IPv4 policy currently in effect. > > Discussion/commentary: in practice, this appears to mean: > > line b) above is presumably intended to be restricted to 4.3 > "End-users - Assignments to end-users", but that isn't clearly stated, > so others may be eligible than desired/intended. > > The current IPv4 criteria states: > >> 4.3.2. Minimum assignment >> >> 4.3.2.1 Single Connection >> >> The minimum block of IP address space assigned by ARIN to >> end-users is a /20. If assignments smaller than /20 are needed, >> end-users should contact their upstream provider. >> >> 4.3.2.2 Multihomed Connection >> >> For end-users who demonstrate an intent to announce the requested >> space in a multihomed fashion, the minimum block of IP address >> space assigned is a /22. If assignments smaller than a /22 are >> needed, multihomed end-users should contact their upstream >> providers. When prefixes are assigned which are longer than /20, >> they will be from a block reserved for that purpose. > > > 2006-04: > >> To qualify for a direct end site assignment, an organization must >> meet >> all of the following criteria: >> >> 1. not be an LIR; >> 2. be an end site; >> 3. be currently multihomed using IPv4; >> 4. have a direct assignment from ARIN of at least a IPv4 /19 and can >> show the current utilization of 80% of an IPv4 /19 equivalent. > And there was a fair amount of discussion as to what term 2 actually means. I am still not sure that there is consensus on this point, and the author has offered to remove it if that would help make things clearer. Regards Marshall > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From tme at multicasttech.com Thu Apr 6 16:09:42 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 6 Apr 2006 16:09:42 -0400 Subject: [ppml] PI Policy 2005-01/2006-04: issues In-Reply-To: <200604061947.k36Jl7md005897@cichlid.raleigh.ibm.com> References: <200604061947.k36Jl7md005897@cichlid.raleigh.ibm.com> Message-ID: <155D0A66-2D61-4B23-A86B-F9155751D9F0@multicasttech.com> Thank you very much for doing this. Regards Marshall On Apr 6, 2006, at 3:47 PM, Thomas Narten wrote: > On Monday afternoon, we will be discussing the two PI for end site > proposals (2005-01 and 2006-04) at the ARIN meeting. The hope is that > during the meeting, we can reach agreement on one proposal (possibly > with modifications) to move forward. On the other hand, I have the > fear that the discussion will fracture, with support split between the > two proposals, a resulting deadlock, and then no clear way > forward. Let's try to avoid that outcome. > > I will be posting several follouwp messages, each one focussed on > comparing key differences of the two proposals. The aim then is to > have discussion on these differences (individually) in order to find > common ground on the key elements. Having discussion of the form "I > like proposal X better" aren't helpful in this context. Discussion > about "I support aspect Y of proposal X, and here is the reason why", > or "I don't think either proposal gets this part exactly right, and > here is what I'd propose instead" would be much more constructive. > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From arin-member at quadrix.com Thu Apr 6 16:18:32 2006 From: arin-member at quadrix.com (Bill Van Emburg) Date: Thu, 06 Apr 2006 15:18:32 -0500 Subject: [ppml] PI Policy 2005-01/2006-04: Eligibility In-Reply-To: References: Message-ID: <44357798.8000308@quadrix.com> > Date: Thu, 06 Apr 2006 15:54:05 -0400 > From: Thomas Narten > Subject: [ppml] PI Policy 2005-01/2006-04: Eligibility > > On qualifications for obtaining a PI assignment: > > 2006-04: > >> To qualify for a direct end site assignment, an organization must meet >> all of the following criteria: >> >> 1. not be an LIR; >> 2. be an end site; >> 3. be currently multihomed using IPv4; >> 4. have a direct assignment from ARIN of at least a IPv4 /19 and can >> show the current utilization of 80% of an IPv4 /19 equivalent. > This is my main objection to 2006-04. This is a little more restrictive than the current policy, and I think that it would be bad to make a more restrictive policy for IPv6 allocation, at this time. Let's do *something* to encourage adoption. We can, in fact, change it later, if necessary.... -Bill Van Emburg From lea.roberts at stanford.edu Thu Apr 6 16:36:40 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Thu, 6 Apr 2006 13:36:40 -0700 (PDT) Subject: [ppml] does 2005-8 need clarification? In-Reply-To: <44357473.1030603@quadrix.com> Message-ID: hi Bill - On Thu, 6 Apr 2006, Bill Van Emburg wrote: > I do not support 2005-8, regardless of whether Scott's interpretation or > Lee's interpretation is correct. I don't think we need to switch to /56 > as default at this time, and I don't think IPv6 end users should be > restricted to getting their IPs from an LIR. as Scott said, 2005-8 is aimed at assignments from ISP/LIRs. It is not at all related to the issues about PI assignments to end users. while the original version of 2005-8 recommended /56 allocations to small users, the current version of 2005-8 was modified in response to comments at the last ARIN meeting that we should not re-establish classful networks in IPv6. It says that assignment size becomes the choice of the provider and removes /48 as the only assignment choice for multiple subnet addressing. the /56 mention in the current version only refers to what would be used to measure the HD ratio, i.e. counting /56s rather than /48s. I'm sorry to hear you don't agree that ISPs ought to be the ones to choose what size address block they assign to a customer who has more than one subnet. are you saying the /48 fits all?? /Lea From sleibrand at internap.com Thu Apr 6 16:43:59 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 6 Apr 2006 16:43:59 -0400 (EDT) Subject: [ppml] PI Policy 2005-01/2006-04: Identifying/filtering prefixes In-Reply-To: <200604061948.k36JmQFM005905@cichlid.raleigh.ibm.com> References: <200604061948.k36JmQFM005905@cichlid.raleigh.ibm.com> Message-ID: On 04/06/06 at 3:48pm -0400, Thomas Narten wrote: > Issue/topic: is it desirable/necessary to be able to identify PI > prefixes for filtering purposes? Yes, definitely. > If so, how will this be achieved? IMO the 2006-04 language is good for this. Ideally we should consider additional mechanisms, but IMO that's best left for a future policy proposal (after we pass a PI policy). -Scott > 2005-01: > > Nothing explicitly stated. no recommendation to assign PI blocks out > of a well-known prefix. > > 2006-04: > > Proposal says: > > > Direct Assignments shall be allocated from a separate super-block > > to allow for LIRs to filter. From sleibrand at internap.com Thu Apr 6 17:09:24 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 6 Apr 2006 17:09:24 -0400 (EDT) Subject: [ppml] PI Policy 2005-01/2006-04: Eligibility In-Reply-To: <200604061954.k36Js5fB005957@cichlid.raleigh.ibm.com> References: <200604061954.k36Js5fB005957@cichlid.raleigh.ibm.com> Message-ID: I prefer 2005-01's language here (which was my primary reason for preferring 2005-01 overall). IMO IPv6 PI space should be available to anyone who qualifies for IPv4 PI space (under the current IPv4 policy), not just to those who've used 80% of a /19. I also don't see a necessity to restrict eligibility to section 4.3. If current or future policies define other classes of non-LIR orgs that are eligible for IPv4 PI space, they should also be eligible for IPv6 PI. -Scott On 04/06/06 at 3:54pm -0400, Thomas Narten wrote: > On qualifications for obtaining a PI assignment: > > 2005-01: > > Proposal says: > > > a) not be an IPv6 LIR; and > > > > b) Qualify for an IPv4 assignment or allocation from ARIN under the > > IPv4 policy currently in effect. > > Discussion/commentary: in practice, this appears to mean: > > line b) above is presumably intended to be restricted to 4.3 > "End-users - Assignments to end-users", but that isn't clearly stated, > so others may be eligible than desired/intended. > > The current IPv4 criteria states: > > > 4.3.2. Minimum assignment > > > > 4.3.2.1 Single Connection > > > > The minimum block of IP address space assigned by ARIN to > > end-users is a /20. If assignments smaller than /20 are needed, > > end-users should contact their upstream provider. > > > > 4.3.2.2 Multihomed Connection > > > > For end-users who demonstrate an intent to announce the requested > > space in a multihomed fashion, the minimum block of IP address > > space assigned is a /22. If assignments smaller than a /22 are > > needed, multihomed end-users should contact their upstream > > providers. When prefixes are assigned which are longer than /20, > > they will be from a block reserved for that purpose. > > > 2006-04: > > > To qualify for a direct end site assignment, an organization must meet > > all of the following criteria: > > > > 1. not be an LIR; > > 2. be an end site; > > 3. be currently multihomed using IPv4; > > 4. have a direct assignment from ARIN of at least a IPv4 /19 and can > > show the current utilization of 80% of an IPv4 /19 equivalent. > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From junkins at ntt.net Thu Apr 6 18:25:52 2006 From: junkins at ntt.net (Doug Junkins) Date: Thu, 6 Apr 2006 15:25:52 -0700 Subject: [ppml] PI Policy 2005-01/2006-04: Identifying/filtering prefixes In-Reply-To: <200604061948.k36JmQFM005905@cichlid.raleigh.ibm.com> References: <200604061948.k36JmQFM005905@cichlid.raleigh.ibm.com> Message-ID: <2071aa39eaf9c10c507de08c771dbd7c@ntt.net> I support 2006-4 and specifically looked for the allocation of PI space from a well known prefix to make filtering easier when and if it becomes necessary. -Doug Junkins NTT America, Global IP Network On Apr 6, 2006, at 12:48 PM, Thomas Narten wrote: > Issue/topic: is it desirable/necessary to be able to identify PI > prefixes for filtering purposes? If so, how will this be achieved? > > 2005-01: > > Nothing explicitely stated. no recommendation to assign PI blocks out > of a well-known prefix. > > 2006-04: > > Proposal says: > >> Direct Assignments shall be allocated from a separate super-block >> to allow for LIRs to filter. > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From woody at pch.net Thu Apr 6 18:49:03 2006 From: woody at pch.net (Bill Woodcock) Date: Thu, 6 Apr 2006 15:49:03 -0700 (PDT) Subject: [ppml] Proposed Policy: Bulk WHOIS agreement expiration clarification In-Reply-To: <624CF0982DBA6604B91227AF@imac-en0.delong.sj.ca.us> References: <443554E4.6020903@arin.net> <624CF0982DBA6604B91227AF@imac-en0.delong.sj.ca.us> Message-ID: On Thu, 6 Apr 2006, Owen DeLong wrote: > ... or upon notice from ARIN to the other party that ARIN believes the > terms were violated... > With the current language, the determination of a violation is left > far too ambiguous for my tastes. Sure, I'm not picky. -Bill From arin-member at quadrix.com Thu Apr 6 19:08:20 2006 From: arin-member at quadrix.com (Bill Van Emburg) Date: Thu, 06 Apr 2006 18:08:20 -0500 Subject: [ppml] does 2005-8 need clarification? In-Reply-To: References: Message-ID: <44359F64.3080008@quadrix.com> Lea Roberts wrote: > to measure the HD ratio, i.e. counting /56s rather than /48s. I'm sorry > to hear you don't agree that ISPs ought to be the ones to choose what size > address block they assign to a customer who has more than one subnet. are > you saying the /48 fits all?? /Lea > I'm saying that I agree with IETF's original assessment as to where to put the site boundary for the time being. I think that folks are a little too concerned with getting it "right," regardless of the near-term difficulties that imposes. I think that folks are a little too concerned with a portion of the address space being allocated differently from what we'll do in 5 or 10 years (or longer). The bigger problem right now is getting anyone to make use of the space. How can we facilitate the conversion of the Internet from IPv4 to IPv6? -Bill Van Emburg From owen at delong.com Thu Apr 6 19:16:59 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 06 Apr 2006 16:16:59 -0700 Subject: [ppml] PI Policy 2005-01/2006-04: Eligibility In-Reply-To: <200604061954.k36Js5fB005957@cichlid.raleigh.ibm.com> References: <200604061954.k36Js5fB005957@cichlid.raleigh.ibm.com> Message-ID: <35D07CC727E88C904ABF029C@odpwrbook.hq.netli.lan> --On April 6, 2006 3:54:05 PM -0400 Thomas Narten wrote: > On qualifications for obtaining a PI assignment: > > 2005-01: > > Proposal says: > >> a) not be an IPv6 LIR; and >> >> b) Qualify for an IPv4 assignment or allocation from ARIN under the >> IPv4 policy currently in effect. > > Discussion/commentary: in practice, this appears to mean: > > line b) above is presumably intended to be restricted to 4.3 > "End-users - Assignments to end-users", but that isn't clearly stated, > so others may be eligible than desired/intended. > As I said to you in private email before you posted this, the intent in 2005-1 is to have an IPv6 PI policy which tracks IPv4 PI policies, making IPv6 no more and no less restrictive than IPv4. While your statement of the effect in practice is accurate today, IPv4 policy could change. I think if IPv4 policy changes, it is desirable to have IPv6 policy track that change until we have enough operational experience with v6 deployment to determine a specific independent policy which would be achieved by amending this policy. There is no intent to limit this to those qualifying for end user assignments only, although qualifying for a subscriber allocation is a true subset of qualifying for an end user allocation at this time. As such, I believe that the proposed language expresses the true intent of the policy authors. (I am one of the authors of 2005-1, so, I'm pretty confident in my understanding of our intent) Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Apr 6 19:20:21 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 06 Apr 2006 16:20:21 -0700 Subject: [ppml] PI Policy 2005-01/2006-04: Eligibility In-Reply-To: References: <200604061954.k36Js5fB005957@cichlid.raleigh.ibm.com> Message-ID: <8722CA2492A4829108FBD909@odpwrbook.hq.netli.lan> >> 2006-04: >> >>> To qualify for a direct end site assignment, an organization must >>> meet >>> all of the following criteria: >>> >>> 1. not be an LIR; >>> 2. be an end site; >>> 3. be currently multihomed using IPv4; >>> 4. have a direct assignment from ARIN of at least a IPv4 /19 and can >>> show the current utilization of 80% of an IPv4 /19 equivalent. >> > > And there was a fair amount of discussion as to what term 2 actually > means. > I am still not sure that there is consensus on this point, and the > author has offered to remove it if that would help make things clearer. > The problem with just removing it is that there could be organizations that SHOULD be LIRs, but, are not yet LIRs that choose to get their initial allocation under this policy. If you do not fit some reasonable model of end-site, then, you probably should be in the LIR policy. If you are selling transit services, for example, you should probably be an LIR and not an end-site. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Apr 6 19:22:36 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 06 Apr 2006 16:22:36 -0700 Subject: [ppml] PI Policy 2005-01/2006-04: Eligibility In-Reply-To: <44357798.8000308@quadrix.com> References: <44357798.8000308@quadrix.com> Message-ID: <24065CDF86669A62E1EF762B@odpwrbook.hq.netli.lan> >> On qualifications for obtaining a PI assignment: >> >> 2006-04: >> >>> To qualify for a direct end site assignment, an organization must meet >>> all of the following criteria: >>> >>> 1. not be an LIR; >>> 2. be an end site; >>> 3. be currently multihomed using IPv4; >>> 4. have a direct assignment from ARIN of at least a IPv4 /19 and can >>> show the current utilization of 80% of an IPv4 /19 equivalent. >> > This is my main objection to 2006-04. This is a little more restrictive > than the current policy, and I think that it would be bad to make a more > restrictive policy for IPv6 allocation, at this time. Let's do > *something* to encourage adoption. We can, in fact, change it later, if > necessary.... > I agree that 2006-4 is too restrictive. However, it is less restrictive than current v6 policy. The current v4 policy is significantly less restrictive than this, but, v6 policy provides absolutely no possibility of PI space to an end-site at this time. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Fri Apr 7 04:10:52 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 7 Apr 2006 09:10:52 +0100 Subject: [ppml] Definition of an (IPv6) End Site In-Reply-To: <021001c65998$5dbf3170$3b3816ac@ssprunk> Message-ID: > A wholly- or partially-owned subsidiary is the interesting case. If someone > showed me contracts for service, a flow of invoices and payments, etc. I'd > probably agree they're separate orgs. If the two had no private > interconnection (e.g. exchanged email over the Internet), I'd agree. If > they shared the same network but had internal "charge-backs", I'd disagree. > There's a lot of gray in between, however. And there is the overall question, does ARIN have the right to make policy on this basis, i.e. the legal arms-length status of the two entities. ARIN is supposed to be a technical organization making policies that have a technical basis. We are not part of the government and we are not supposed to be dealing with public policy in the generic sense. > However, that same hole has apparently been abused by enterprises as well, > and there's a _lot_ of private businesses out there. Is Cisco really a LIR? > Is IBM? Only the biggest companies are doing it so far, but those are also > the folks that will be telling _their customers_ to do the same as a "best > practice", complete with slideware on how to do it. Perhaps this is because of the fact that we have no reasonable PI policy. If we had a policy that essentially allows an enterprise to be a mini-LIR, then this will likely go away. However, if we make a PI policy with rules that are significantly different from the rules of PA assignment by an LIR, then we can expect people to still go after LIR status. Since we do not carry a big stick, I favor having a PI policy that is as liberal as PA assignment rules for LIRs. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 7 04:15:02 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 7 Apr 2006 09:15:02 +0100 Subject: [ppml] Summary of IPv6 assignment proposals In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401BD9DA1@CL-S-EX-1.stanleyassociates.com> Message-ID: > This message is not sponsored by ARIN. I just can't tell who is in > favor of what. I think we need to dissect all 3 policies into their component parts, post a list of all the unique components and get people to select from that list. Then once we have some consensus on the elements of an IPv6 policy it should be straightforward to write it up as a coherent set of changes to existing policy. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 7 04:23:20 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 7 Apr 2006 09:23:20 +0100 Subject: [ppml] PI Policy 2005-01/2006-04: Identifying/filtering prefixes In-Reply-To: <200604061948.k36JmQFM005905@cichlid.raleigh.ibm.com> Message-ID: > Issue/topic: is it desirable/necessary to be able to identify PI > prefixes for filtering purposes? If so, how will this be achieved? Yes, all PI addresses must come out of a defined address range that is used only for PI addresses. Further, I think that we should specify at least some of ARIN's allocation algorithm here. Since PI blocks are intended to go to private enterprises who do not constantly grow their networks as fast as ISPs, we should specify that ARIN does not use any sparse allocation techniques intended to reserve additional space for an applicant. And, of course, you all know that I think ARIN's algorithm should include selecting the address from subranges associated with the geographical region in which the applicant's main connectivity is located. This is to be determined by asking the applicant in which city their main connectivity will be. And, of course, ARIN will reserve sufficient space for each subrange so that the range is unlikely to be used up for the foreseeable future, say 10 years. No doubt this will require ARIN to apply to IANA for the required address space. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 7 04:24:58 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 7 Apr 2006 09:24:58 +0100 Subject: [ppml] PI Policy 2005-01/2006-04: On maximum assigned prefix In-Reply-To: <200604061951.k36JpiuX005935@cichlid.raleigh.ibm.com> Message-ID: > On maximum size of assigned prefix: /31 After that LIR sizing rules should apply. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 7 04:27:41 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 7 Apr 2006 09:27:41 +0100 Subject: [ppml] PI Policy 2005-01/2006-04: criteria for obtaining additional space In-Reply-To: <200604061952.k36Jqa8G005943@cichlid.raleigh.ibm.com> Message-ID: > On justification for more address space than the default: This depends on the definition of end-site. If the default PI assignment is /48, i.e. one end-site, then they must show a requirement for additional end-sites to justify additional /48s. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 7 04:33:29 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 7 Apr 2006 09:33:29 +0100 Subject: [ppml] PI Policy 2005-01/2006-04: Eligibility In-Reply-To: <200604061954.k36Js5fB005957@cichlid.raleigh.ibm.com> Message-ID: > > a) not be an IPv6 LIR; and > > > > b) Qualify for an IPv4 assignment or allocation from ARIN under the > > IPv4 policy currently in effect. These are two different things and should be separated. To qualify for a PI assignment, you must: a) not already be an IPv6 LIR. b) have an AS number If the resulting policy has any barriers that would prevent an IPv4 PI assignment holder from getting an IPv6 PI allocation then we could have a fastpath in which the justification comes from the fact that the IPv4 PI holder is already multihomed using IPv4. This migration clause is only needed if the final policy has something that would create a barrier. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 7 04:36:24 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 7 Apr 2006 09:36:24 +0100 Subject: [ppml] PPML Digest, Vol 10, Issue 10 In-Reply-To: <44357473.1030603@quadrix.com> Message-ID: > Most importantly, I think we need to make it very explicit that there is > no "permanent" IPv6 assignment. ARIN *must* retain the right to reclaim > IPv6 addresses at a later date, if the user can not justify it under the > then-current policy. I also think that allocations should be required > to be returned to ARIN or re-justified when another organization takes > over the IP space. IPs are not an asset to be bought and sold > privately; they are a public trust. This is already in 6.4.1 of the IPv6 policy. --Michael Dillon From andrew.dul at quark.net Fri Apr 7 12:20:58 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Fri, 07 Apr 2006 16:20:58 +0000 Subject: [ppml] IPv6 PI Assignment Survey Message-ID: <20060407162058.19872.qmail@hoster908.com> I'd like to thank Thomas Narten for posting his messages yesterday encouraging people to post their comments to PPML. I also realize that not everyone can post their comments or wishes to send lots of "me too" emails, but may still want to express their opinion. I've created an online survey where I've attempted to capture the questions Thomas posted yesterday in an online form. I'm hopefully that this will help the authors of the two IPv6 PI policies craft an IPv6 PI policy which will gain consensus at the upcoming meeting in Montreal. Please take a minute and go to the following URL to fill out the short survey. http://www.quark.net/survey/survey.php?sid=28 This *not* an ARIN sponsored survey, but I will post the results of data that is collected to PPML on Monday morning April 10, 2006. Thanks for your participation, Andrew From tme at multicasttech.com Fri Apr 7 12:34:07 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 7 Apr 2006 12:34:07 -0400 Subject: [ppml] IPv6 PI Assignment Survey In-Reply-To: <20060407162058.19872.qmail@hoster908.com> References: <20060407162058.19872.qmail@hoster908.com> Message-ID: <3F493E19-B1D0-4BE3-B5EB-BEF6F71A834B@multicasttech.com> Thanks for doing this. Two places with possible ambiguities : - Questions 2. I support an IPv6 PI assignment to any organization which qualifies for an IPv4 assignment. and 3. I support an IPv6 PI policy which requires other criteria. (Other than any IPv4 assignment) are not mutually exclusive. (For example, I support a IPv6 only assignment policy for networks without a IPv4 footprint.) So I answered "yes" to both. - Is a minimum assignment the shortest prefix or the smallest block allowed ? (and the obvious inverse for maximum) I assume smallest block. Regards Marshall On Apr 7, 2006, at 12:20 PM, Andrew Dul wrote: > I'd like to thank Thomas Narten for posting his messages yesterday > encouraging people to post their comments to PPML. > > I also realize that not everyone can post their comments or wishes > to send lots of "me too" emails, but may still want to express > their opinion. > > I've created an online survey where I've attempted to capture the > questions Thomas posted yesterday in an online form. I'm hopefully > that this will help the authors of the two IPv6 PI policies craft > an IPv6 PI policy which will gain consensus at the upcoming meeting > in Montreal. > > Please take a minute and go to the following URL to fill out the > short survey. > > http://www.quark.net/survey/survey.php?sid=28 > > This *not* an ARIN sponsored survey, but I will post the results of > data that is collected to PPML on Monday morning April 10, 2006. > > Thanks for your participation, > Andrew > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From andrew.dul at quark.net Fri Apr 7 13:10:58 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Fri, 07 Apr 2006 17:10:58 +0000 Subject: [ppml] IPv6 PI Assignment Survey Message-ID: <20060407171058.25419.qmail@hoster908.com> -------Original Message------- > From: Marshall Eubanks > Subject: Re: [ppml] IPv6 PI Assignment Survey > Sent: 07 Apr '06 08:34 > > Thanks for doing this. > > Two places with possible ambiguities : > > - Questions > > 2. I support an IPv6 PI assignment to any organization which > qualifies for an IPv4 assignment. > and > 3. I support an IPv6 PI policy which requires other criteria. (Other > than any IPv4 assignment) > > are not mutually exclusive. (For example, I support a IPv6 only > assignment policy for networks > without a IPv4 footprint.) > > So I answered "yes" to both. I didn't assume they were mutually exclusive so answering, yes to both is perfectly acceptable. I did that too when I added my opinion. > - Is a minimum assignment the shortest prefix or the smallest block > allowed ? > (and the obvious inverse for maximum) > > I assume smallest block. > That was my assumption too. Both of the exiting policies assume /48 as the smallest block. > On Apr 7, 2006, at 12:20 PM, Andrew Dul wrote: > > > I'd like to thank Thomas Narten for posting his messages yesterday > > encouraging people to post their comments to PPML. > > > > I also realize that not everyone can post their comments or wishes > > to send lots of "me too" emails, but may still want to express > > their opinion. > > > > I've created an online survey where I've attempted to capture the > > questions Thomas posted yesterday in an online form. I'm hopefully > > that this will help the authors of the two IPv6 PI policies craft > > an IPv6 PI policy which will gain consensus at the upcoming meeting > > in Montreal. > > > > Please take a minute and go to the following URL to fill out the > > short survey. > > > > http://www.quark.net/survey/survey.php?sid=28 > > > > This *not* an ARIN sponsored survey, but I will post the results of > > data that is collected to PPML on Monday morning April 10, 2006. > > > > Thanks for your participation, > > Andrew > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > From sleibrand at internap.com Fri Apr 7 13:25:48 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 7 Apr 2006 13:25:48 -0400 (EDT) Subject: [ppml] IPv6 PI Assignment Survey In-Reply-To: <20060407162058.19872.qmail@hoster908.com> References: <20060407162058.19872.qmail@hoster908.com> Message-ID: In the survey, you ask: > 4. Should the requirement of "end-site" as defined in the current IPv6 > policy be a requirement for a PI assignment? In the NRPM, 6.2.9. End site requires that and end site have "a business relationship with a service provider that involves:" > 4. that service provider advertising an aggregate prefix route > that contains the end user's assignment This provision of the end-site definition is mutually exclusive, IMO, with provider independence. -Scott On 04/07/06 at 4:20pm -0000, Andrew Dul wrote: > I'd like to thank Thomas Narten for posting his messages yesterday encouraging people to post their comments to PPML. > > I also realize that not everyone can post their comments or wishes to send lots of "me too" emails, but may still want to express their opinion. > > I've created an online survey where I've attempted to capture the questions Thomas posted yesterday in an online form. I'm hopefully that this will help the authors of the two IPv6 PI policies craft an IPv6 PI policy which will gain consensus at the upcoming meeting in Montreal. > > Please take a minute and go to the following URL to fill out the short survey. > > http://www.quark.net/survey/survey.php?sid=28 > > This *not* an ARIN sponsored survey, but I will post the results of data that is collected to PPML on Monday morning April 10, 2006. > > Thanks for your participation, > Andrew > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Fri Apr 7 13:32:36 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 7 Apr 2006 13:32:36 -0400 (EDT) Subject: [ppml] IPv6 PI Assignment Survey In-Reply-To: <20060407162058.19872.qmail@hoster908.com> References: <20060407162058.19872.qmail@hoster908.com> Message-ID: One additional clarification of my opinion as expressed in the survey: The survey asks whether "an organization must have a current IPv4 assignment", and "What size of IPv4 assignment should the organization have to qualify for an IPv6 PI assignment?" IMO neither of these questions includes an important (assumed?) condition, which in my case is that an organization must be *eligible for* (not necessarily *have*) an IPv4 *PI* assignment *from ARIN*. IMO question 7, particularly, could be read as including anyone with IPv4 PA space. -Scott On 04/07/06 at 4:20pm -0000, Andrew Dul wrote: > I'd like to thank Thomas Narten for posting his messages yesterday encouraging people to post their comments to PPML. > > I also realize that not everyone can post their comments or wishes to send lots of "me too" emails, but may still want to express their opinion. > > I've created an online survey where I've attempted to capture the questions Thomas posted yesterday in an online form. I'm hopefully that this will help the authors of the two IPv6 PI policies craft an IPv6 PI policy which will gain consensus at the upcoming meeting in Montreal. > > Please take a minute and go to the following URL to fill out the short survey. > > http://www.quark.net/survey/survey.php?sid=28 > > This *not* an ARIN sponsored survey, but I will post the results of data that is collected to PPML on Monday morning April 10, 2006. > > Thanks for your participation, > Andrew > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Fri Apr 7 13:55:45 2006 From: randy at psg.com (Randy Bush) Date: Fri, 7 Apr 2006 07:55:45 -1000 Subject: [ppml] IPv6 PI Assignment Survey References: <20060407162058.19872.qmail@hoster908.com> Message-ID: <17462.42913.891311.191329@roam.psg.com> good idea too see where folk stand. though i am not in favor of making engineering and architecture decisions by vote. randy From owen at delong.com Fri Apr 7 14:46:43 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 07 Apr 2006 11:46:43 -0700 Subject: [ppml] IPv6 PI Assignment Survey In-Reply-To: <20060407162058.19872.qmail@hoster908.com> References: <20060407162058.19872.qmail@hoster908.com> Message-ID: I'd like to thank Thomas for his questions as well. Further, I'd like to thank Andrew for putting this survey together. I hope people will take the time to answer the questions there. Andrew, Kevin, and I will be meeting sometime between our arrivals in Montreal and Monday morning to try and come closer to consensus with our policies. We will use the results from this survey as input into that process. In case you didn't catch the survey URL from Andrew's email, it can be found here: Thanks, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Fri Apr 7 14:48:26 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 07 Apr 2006 11:48:26 -0700 Subject: [ppml] IPv6 PI Assignment Survey In-Reply-To: <3F493E19-B1D0-4BE3-B5EB-BEF6F71A834B@multicasttech.com> References: <20060407162058.19872.qmail@hoster908.com> <3F493E19-B1D0-4BE3-B5EB-BEF6F71A834B@multicasttech.com> Message-ID: <0E7B680736D016467D385750@imac-en0.delong.sj.ca.us> --On April 7, 2006 12:34:07 PM -0400 Marshall Eubanks wrote: > Thanks for doing this. > > Two places with possible ambiguities : > > - Questions > > 2. I support an IPv6 PI assignment to any organization which > qualifies for an IPv4 assignment. > and > 3. I support an IPv6 PI policy which requires other criteria. (Other > than any IPv4 assignment) > > are not mutually exclusive. (For example, I support a IPv6 only > assignment policy for networks > without a IPv4 footprint.) > > So I answered "yes" to both. > That is as I would expect. > - Is a minimum assignment the shortest prefix or the smallest block > allowed ? > (and the obvious inverse for maximum) > > I assume smallest block. > You are correct. Shortest prefix would be a maximum assignment. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Fri Apr 7 14:52:33 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 07 Apr 2006 11:52:33 -0700 Subject: [ppml] IPv6 PI Assignment Survey In-Reply-To: <17462.42913.891311.191329@roam.psg.com> References: <20060407162058.19872.qmail@hoster908.com> <17462.42913.891311.191329@roam.psg.com> Message-ID: Well, since what we are talking about is neither an engineering, nor an architecture decision, that should sit well with you. This is an IP Public Policy decision and discussion. True, the policy will effect engineering and architecture, but, the decision is a policy decision. As a public policy decision, I believe a vote is the best mechanism yet discovered for determining the public will. Owen --On April 7, 2006 7:55:45 AM -1000 Randy Bush wrote: > good idea too see where folk stand. though i am not in favor of > making engineering and architecture decisions by vote. > > randy > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From marla_azinger at eli.net Fri Apr 7 17:09:02 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 7 Apr 2006 14:09:02 -0700 Subject: [ppml] IPv6 PI Assignment Survey Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100CFC@wava00s2ke2k01.corp.pvt> Thank you for doing this survey set up. Its a great way to get feed back and clarify what the issues are. I did the survey, but I have a few reservations about the question asked. I put my concerns below each question of the survey I have "input" on. #5. I support the requirement that an organization must be multihomed to qualify for an IPv6 PI assignment. "My point of hesitation on this is that how can we require this when we dont have a multihome solution. Yes, I know you can do it just like v4 but policy doesnt support that. So I say "agree" if we can change policy to support current technical abilities". #8. I support the requirement to assign IPv6 PI address space from a seperate super block. "My point of hesitation here is the whole reason for seperating the super block. If I interpret this correctly, we are doing this so that PI assignments are allowed to deaggregate within the super block. I dont see this as a fair practice due to the fact with current policy anyone else outside of this PI superblock that uses the regular v6 block arnt allowed to deagregate thus multihome. So this rule would only allow PI assignements the ability to deagregate and multihome. 13. I support the requirement to specify a reserved block in an IPv6 PI address policy. "sorry, havnt followed the chain of emails enough to know if you are talking about ARIN publicly announcing what Super block is to be reserved for this use or when an ARIN Member requesting the next contiguous block to be reserved for futer request" 15. I support the assignment of additional /48 subnets to organizations with multiple assigned ASNs. "The way policy is right now I agree with this. But would it possibly be better to reduce the size to a /44 and change policy?" 16. I support the assignment of multiple /48s per organization. "Yes, given there is technical need demanding this or usage justified" Thank you Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Andrew Dul Sent: Friday, April 07, 2006 9:21 AM To: ppml at arin.net Subject: [ppml] IPv6 PI Assignment Survey I'd like to thank Thomas Narten for posting his messages yesterday encouraging people to post their comments to PPML. I also realize that not everyone can post their comments or wishes to send lots of "me too" emails, but may still want to express their opinion. I've created an online survey where I've attempted to capture the questions Thomas posted yesterday in an online form. I'm hopefully that this will help the authors of the two IPv6 PI policies craft an IPv6 PI policy which will gain consensus at the upcoming meeting in Montreal. Please take a minute and go to the following URL to fill out the short survey. http://www.quark.net/survey/survey.php?sid=28 This *not* an ARIN sponsored survey, but I will post the results of data that is collected to PPML on Monday morning April 10, 2006. Thanks for your participation, Andrew _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From dsd at servervault.com Fri Apr 7 22:41:10 2006 From: dsd at servervault.com (Divins, David) Date: Fri, 7 Apr 2006 22:41:10 -0400 Subject: [ppml] Privacy of Reassignment Information Message-ID: All, Provided an ISP, or other direct assignment recipient, supplies valid and responsive (24x7) Abuse, NOC, and other pertinent contact information, a reassignment should be allowed to remain private. This has been discussed before and abandoned (http://www.arin.net/policy/proposals/2004_6.html). However, I feel this issue needs to be raised again as it is more important than ever. There are ample valid reasons for a reassignment to remain private. ISP's may not want their customers to be mined via a public service. Many companies only use their assignment for private business exchanges and do not want a public vector into their block. HIPAA clearing facilities, banking exchanges, procurement systems are all example of viable private reassignments. Note also that visibility into a companies assignments makes forging DoS attacks or phishing schemes much easier, and this is a concern for some organizations. The ability for an ISP to selectively and voluntarily make an assignment private will still allow ARIN to have accurate reassignment information as the assignments will be provided to ARIN privately whenever address utilization must be determined. The private designation in no way relieves the ISP of its responsibility to the Internet community. In fact, a private reassignment expands this responsibility as the ISP actually must take on the responsibility providing valid 24x7 point of contact. If an ISP is unable or unwilling to provide a responsive NOC/abuse contact, then they may not designate any reassignments as private. I will be at the Montreal meeting and plan on raising this issue during the open policy and/or open mic sessions. Thank you, dsd David Divins Principal Engineer ServerVault Corp. From owen at delong.com Fri Apr 7 23:26:18 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 07 Apr 2006 20:26:18 -0700 Subject: [ppml] IPv6 PI Assignment Survey In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100CFC@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100CFC@wava00s2ke2k01.corp.pv t> Message-ID: Glad to see your comments, Marla. I make an attempt at addressing your feedback inline. Initially, I was just going to send this to you, but, I realized similar confusion might affect other PPML subscribers, so, I sent this to the list. --On April 7, 2006 2:09:02 PM -0700 "Azinger, Marla" wrote: > Thank you for doing this survey set up. Its a great way to get feed back > and clarify what the issues are. > > I did the survey, but I have a few reservations about the question asked. > I put my concerns below each question of the survey I have "input" on. > ># 5. I support the requirement that an organization must be multihomed to ># qualify for an IPv6 PI assignment. > > "My point of hesitation on this is that how can we require this when we > dont have a multihome solution. Yes, I know you can do it just like v4 > but policy doesnt support that. So I say "agree" if we can change policy > to support current technical abilities". > The intent behind this question is to evaluate what people think we should change the policy to. In other words, if you support having a PI IPv6 policy, should it include a multihoming requirement. Essentially, we're asking "Should we change policy to support current technical requirements." As such, I hope you answered yes. ># 8. I support the requirement to assign IPv6 PI address space from a ># seperate super block. > > "My point of hesitation here is the whole reason for seperating the super > block. If I interpret this correctly, we are doing this so that PI > assignments are allowed to deaggregate within the super block. I dont > see this as a fair practice due to the fact with current policy anyone > else outside of this PI superblock that uses the regular v6 block arnt > allowed to deagregate thus multihome. So this rule would only allow PI > assignements the ability to deagregate and multihome. > Actually, the purpose for this is to allow providers who don't want to carry these PI routes to filter them without affecting ISP-based routes. Further, since PI allocations might be longer prefixes (/48) than ISP allocations (/32), it might be desirable to have a unique block to support different filter sets. Theoretically, the purpose behind having ISPs get a /32 is to prevent the need for them to deaggregate. The purpose behind having PI is to allow organizations to multihome without needing PA blocks. Obviously, most organizations don't need an entire ISP worth of network space. A deaggregated LIR should be 2 (or more) LIRs. > 13. I support the requirement to specify a reserved block in an IPv6 PI > address policy. > > "sorry, havnt followed the chain of emails enough to know if you are > talking about ARIN publicly announcing what Super block is to be reserved > for this use or when an ARIN Member requesting the next contiguous block > to be reserved for futer request" > Basically whether we should do sparse allocation in the PI range so that an organization which receives a /48 and later needs a /47 could simply be assigned the next consecutive /48 such that it aggregated into a /47. Further, how sparse should this be? /48, /47.../44?... > > 15. I support the assignment of additional /48 subnets to organizations > with multiple assigned ASNs. > > "The way policy is right now I agree with this. But would it possibly be > better to reduce the size to a /44 and change policy?" > /44 would be increasing the size while reducing the prefix length. However, the question here is more about whether the number of ASNs you possess should be counted as a factor in the amount of address space you can justify. > 16. I support the assignment of multiple /48s per organization. > > "Yes, given there is technical need demanding this or usage justified" > Yes... Those two factors are common to both policies provisions for additional space and I don't think anyone has suggested that additional /48s should be provided without justification. Hope that clarifies things for you. Just in the interest of full disclosure, I didn't write the survey, but, I did write one of the two policy proposals that the survey addresses. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From william at elan.net Sat Apr 8 22:09:00 2006 From: william at elan.net (william(at)elan.net) Date: Sat, 8 Apr 2006 19:09:00 -0700 (PDT) Subject: [ppml] [arin-discuss] Privacy of Reassignment Information In-Reply-To: <58B7D661D526AD5023B1FF75@imac-en0.delong.sj.ca.us> References: <0af901c65b1a$17b2d0f0$750da8c0@axsdom.local> <58B7D661D526AD5023B1FF75@imac-en0.delong.sj.ca.us> Message-ID: On Sat, 8 Apr 2006, Owen DeLong wrote: > Education is the answer to phishing. Hiding private information doesn't > actually help. The reality is that I can't recall ever receiving a > phishing attempt that used information from whois. The phishers > don't generally bother. For one thing, there isn't a high enough > percentage of targets with whois entries. It happened and was in fact domain registration related phishing (apparently to get domain password), but this has nothing to do with ip whois. The reality is that ip whois is rarely used for spam target harvesting (but not never and doing so is not illegal or against arin policies) and when it is, that is mostly to send service offers to ISPs, ASPs and other companies with presence on the internet. Additionally phishing requires email address and other contact information where as IP whois publication is only required for name and address and only for businesses. So I really don't see how ip whois data can have anything to do with phishing. > My opinions are based exactly on the fact, as I stated, that IP addresses > are a resource assigned from the public trust. If you obtain the use of > federal land, that use permit is a matter of public record. I don't see > any reason IP address assignments should be treated any differently. > Resource allocations in the public trust should be a matter of public > record. I entirely agree. BTW - for people who worry about privacy and phishing may I remind that your tax records are in fact public information (at least in US), what do you think provides more useful data that or whois if somebody wants to use this for fraud? Reality is that there is tons of data already in public records on everyone and especially on corporations/businesses and all that data is of a lot more interest to abusers then what is in whois (difference is that whois is easy to query and use, but in practice if anyone wants to do something bad, they'd go for more useful info anyway). The real issue is that some ISPs don't want to provide records on who is using their ip space. This is for various reasons - some are concerned about privacy as it related to their business business relationships, some want to hide that they are dealings with certain "net abusers" (this is really subset of business relationship issue) and some are just lazy and want to reduce amount of work they have to do (i.e. publishing and maintaining SWIPs is extra work). --- William Leibzon Elan Networks william at elan.net From heldal at eml.cc Mon Apr 10 07:52:52 2006 From: heldal at eml.cc (Per Heldal) Date: Mon, 10 Apr 2006 13:52:52 +0200 Subject: [ppml] [address-policy-wg] RE: Question In-Reply-To: <001e01c65b13$c472c540$8482fea9@ipv6forum> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> Message-ID: <1144669972.7517.258725818@webmail.messagingengine.com> On Sat, 8 Apr 2006 15:52:56 +0200, "Latif Ladid (The New Internet based on IPv6)" said: > The technical community should fix this one before the ITU sees this as > another chance to have a political say on the IPv6 addressing. These > things > leak fast. My advice is that ARIN should seriously own this issue before > the > ITU turns it to a sovereignty issue, which they could for sure win this > time. I know one of their noodles is sizzling at it. ARIN, and all the other RIRs, represent the interests of people in their region. Anybody who is interested, yourself included, is welcome to suggest changes to current policies. I'm sure RIR-staff are happy to guide you through the process. However, to succeed you need to convince the RIR community that there is a need for a change. It's interesting to see how people are worried about ITU involvement. I share some concerns, but remember; the ITU and their OSI protocols were once at the core of everything in large-scale networking. Those were left behind because they were not flexible enough to keep up with the pace of internet growth in the '90s. ITU as an organization is just as inflexible today as they were 10 or 15 years ago, maybe even worse. To consider ITU a threat to the internet community speaks heaps about how the community has deteriorated over the last decade. Parts of the community are already mirroring ITU behaviour, with or without ITU-involvement. //per -- Per Heldal http://heldal.eml.cc/ From christopher.morrow at gmail.com Mon Apr 10 10:42:02 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 10 Apr 2006 10:42:02 -0400 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: References: Message-ID: <75cb24520604100742w16a7bcdeyfca0cf3bda8fdb78@mail.gmail.com> On 4/7/06, Divins, David wrote: > All, > > Provided an ISP, or other direct assignment recipient, supplies valid > and responsive (24x7) Abuse, NOC, and other pertinent contact > information, a reassignment should be allowed to remain private. > > This has been discussed before and abandoned > (http://www.arin.net/policy/proposals/2004_6.html). However, I feel > this issue needs to be raised again as it is more important than ever. > > There are ample valid reasons for a reassignment to remain private. > > ISP's may not want their customers to be mined via a public service. > Many companies only use their assignment for private business exchanges > and do not want a public vector into their block. HIPAA clearing > facilities, banking exchanges, procurement systems are all example of > viable private reassignments. > I might have missed something in the policy and this note... but, doesn't the ability to use rwhois and limit access to 'arin' solve this privacy issue as well? With this capability perhaps the need to construct policy around privacy of information isn't necessary? -Chris From dsd at servervault.com Mon Apr 10 10:59:00 2006 From: dsd at servervault.com (Divins, David) Date: Mon, 10 Apr 2006 10:59:00 -0400 Subject: [ppml] Privacy of Reassignment Information Message-ID: Chris, According to ARIN policy an RWHOIS server must be always on and be able to be queried by the public. It may not be firewalled to just allow ARIN access :-( I just checked with ARIN staff as I am in Montreal. Thanks, dsd From marla_azinger at eli.net Mon Apr 10 10:56:34 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Mon, 10 Apr 2006 07:56:34 -0700 Subject: [ppml] Privacy of Reassignment Information Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A4FC@wava00s2ke2k01.corp.pvt> I'm not sure if I interpreted Davids question correctly. However, RWHOIS does not permit Privacy that isnt allowed on ARIN WHOIS. The information on RWHOIS should be identical to what would be on ARIN WHOIS. Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Christopher Morrow Sent: Monday, April 10, 2006 7:42 AM To: Divins, David Cc: ppml at arin.net Subject: Re: [ppml] Privacy of Reassignment Information On 4/7/06, Divins, David wrote: > All, > > Provided an ISP, or other direct assignment recipient, supplies valid > and responsive (24x7) Abuse, NOC, and other pertinent contact > information, a reassignment should be allowed to remain private. > > This has been discussed before and abandoned > (http://www.arin.net/policy/proposals/2004_6.html). However, I feel > this issue needs to be raised again as it is more important than ever. > > There are ample valid reasons for a reassignment to remain private. > > ISP's may not want their customers to be mined via a public service. > Many companies only use their assignment for private business exchanges > and do not want a public vector into their block. HIPAA clearing > facilities, banking exchanges, procurement systems are all example of > viable private reassignments. > I might have missed something in the policy and this note... but, doesn't the ability to use rwhois and limit access to 'arin' solve this privacy issue as well? With this capability perhaps the need to construct policy around privacy of information isn't necessary? -Chris _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From aaronh at bind.com Mon Apr 10 11:02:48 2006 From: aaronh at bind.com (Aaron Hughes) Date: Mon, 10 Apr 2006 11:02:48 -0400 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D20295A4FC@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D20295A4FC@wava00s2ke2k01.corp.pvt> Message-ID: <20060410150248.GD17436@user1.bind.com> Marla, agreed. The current methodology is simply to lie, so while several people may have issues with protecting this data, we need to find a way to create a policy to allow for this privacy in order to get accurate data imho. Aaron On Mon, Apr 10, 2006 at 07:56:34AM -0700, Azinger, Marla wrote: > I'm not sure if I interpreted Davids question correctly. However, RWHOIS does not permit Privacy that isnt allowed on ARIN WHOIS. The information on RWHOIS should be identical to what would be on ARIN WHOIS. > > Marla > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Christopher Morrow > Sent: Monday, April 10, 2006 7:42 AM > To: Divins, David > Cc: ppml at arin.net > Subject: Re: [ppml] Privacy of Reassignment Information > > > On 4/7/06, Divins, David wrote: > > All, > > > > Provided an ISP, or other direct assignment recipient, supplies valid > > and responsive (24x7) Abuse, NOC, and other pertinent contact > > information, a reassignment should be allowed to remain private. > > > > This has been discussed before and abandoned > > (http://www.arin.net/policy/proposals/2004_6.html). However, I feel > > this issue needs to be raised again as it is more important than ever. > > > > There are ample valid reasons for a reassignment to remain private. > > > > ISP's may not want their customers to be mined via a public service. > > Many companies only use their assignment for private business exchanges > > and do not want a public vector into their block. HIPAA clearing > > facilities, banking exchanges, procurement systems are all example of > > viable private reassignments. > > > > I might have missed something in the policy and this note... but, > doesn't the ability to use rwhois and limit access to 'arin' solve > this privacy issue as well? With this capability perhaps the need to > construct policy around privacy of information isn't necessary? > > -Chris > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- 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 marla_azinger at eli.net Mon Apr 10 11:11:47 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Mon, 10 Apr 2006 08:11:47 -0700 Subject: [ppml] Privacy of Reassignment Information Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100CFD@wava00s2ke2k01.corp.pvt> I agree we need policy that gives residential privacy but at the same time supports the "research" community. ie Mandatory info is: Residential 23456 upstream abuse contact info or Residential 3V6 (hope I got that right. Not sure if canadian postal starts with number or letter) upstream abuse contact info -----Original Message----- From: Aaron Hughes [mailto:aaronh at bind.com] Sent: Monday, April 10, 2006 8:03 AM To: Azinger, Marla Cc: Christopher Morrow; Divins, David; ppml at arin.net Subject: Re: [ppml] Privacy of Reassignment Information Marla, agreed. The current methodology is simply to lie, so while several people may have issues with protecting this data, we need to find a way to create a policy to allow for this privacy in order to get accurate data imho. Aaron On Mon, Apr 10, 2006 at 07:56:34AM -0700, Azinger, Marla wrote: > I'm not sure if I interpreted Davids question correctly. However, RWHOIS does not permit Privacy that isnt allowed on ARIN WHOIS. The information on RWHOIS should be identical to what would be on ARIN WHOIS. > > Marla > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Christopher Morrow > Sent: Monday, April 10, 2006 7:42 AM > To: Divins, David > Cc: ppml at arin.net > Subject: Re: [ppml] Privacy of Reassignment Information > > > On 4/7/06, Divins, David wrote: > > All, > > > > Provided an ISP, or other direct assignment recipient, supplies valid > > and responsive (24x7) Abuse, NOC, and other pertinent contact > > information, a reassignment should be allowed to remain private. > > > > This has been discussed before and abandoned > > (http://www.arin.net/policy/proposals/2004_6.html). However, I feel > > this issue needs to be raised again as it is more important than ever. > > > > There are ample valid reasons for a reassignment to remain private. > > > > ISP's may not want their customers to be mined via a public service. > > Many companies only use their assignment for private business exchanges > > and do not want a public vector into their block. HIPAA clearing > > facilities, banking exchanges, procurement systems are all example of > > viable private reassignments. > > > > I might have missed something in the policy and this note... but, > doesn't the ability to use rwhois and limit access to 'arin' solve > this privacy issue as well? With this capability perhaps the need to > construct policy around privacy of information isn't necessary? > > -Chris > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- 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 aaronh at bind.com Mon Apr 10 11:15:42 2006 From: aaronh at bind.com (Aaron Hughes) Date: Mon, 10 Apr 2006 11:15:42 -0400 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100CFD@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100CFD@wava00s2ke2k01.corp.pvt> Message-ID: <20060410151542.GE17436@user1.bind.com> Businesses are people too ;) Are you against "Private Business" with zipcode and admin, noc, etc contact info? Aaron On Mon, Apr 10, 2006 at 08:11:47AM -0700, Azinger, Marla wrote: > I agree we need policy that gives residential privacy but at the same time supports the "research" community. > > ie Mandatory info is: > > Residential > 23456 > upstream abuse contact info > > or > > Residential > 3V6 (hope I got that right. Not sure if canadian postal starts with number or letter) > upstream abuse contact info > > -----Original Message----- > From: Aaron Hughes [mailto:aaronh at bind.com] > Sent: Monday, April 10, 2006 8:03 AM > To: Azinger, Marla > Cc: Christopher Morrow; Divins, David; ppml at arin.net > Subject: Re: [ppml] Privacy of Reassignment Information > > > Marla, agreed. > > The current methodology is simply to lie, so while several people may have issues with protecting this data, we need to find a way to create a policy to allow for this privacy in order to get accurate data imho. > > Aaron > > On Mon, Apr 10, 2006 at 07:56:34AM -0700, Azinger, Marla wrote: > > I'm not sure if I interpreted Davids question correctly. However, RWHOIS does not permit Privacy that isnt allowed on ARIN WHOIS. The information on RWHOIS should be identical to what would be on ARIN WHOIS. > > > > Marla > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > > Christopher Morrow > > Sent: Monday, April 10, 2006 7:42 AM > > To: Divins, David > > Cc: ppml at arin.net > > Subject: Re: [ppml] Privacy of Reassignment Information > > > > > > On 4/7/06, Divins, David wrote: > > > All, > > > > > > Provided an ISP, or other direct assignment recipient, supplies valid > > > and responsive (24x7) Abuse, NOC, and other pertinent contact > > > information, a reassignment should be allowed to remain private. > > > > > > This has been discussed before and abandoned > > > (http://www.arin.net/policy/proposals/2004_6.html). However, I feel > > > this issue needs to be raised again as it is more important than ever. > > > > > > There are ample valid reasons for a reassignment to remain private. > > > > > > ISP's may not want their customers to be mined via a public service. > > > Many companies only use their assignment for private business exchanges > > > and do not want a public vector into their block. HIPAA clearing > > > facilities, banking exchanges, procurement systems are all example of > > > viable private reassignments. > > > > > > > I might have missed something in the policy and this note... but, > > doesn't the ability to use rwhois and limit access to 'arin' solve > > this privacy issue as well? With this capability perhaps the need to > > construct policy around privacy of information isn't necessary? > > > > -Chris > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > -- > > 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/ -- 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 marla_azinger at eli.net Mon Apr 10 11:17:13 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Mon, 10 Apr 2006 08:17:13 -0700 Subject: [ppml] Privacy of Reassignment Information Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A4FF@wava00s2ke2k01.corp.pvt> Totally -----Original Message----- From: Aaron Hughes [mailto:aaronh at bind.com] Sent: Monday, April 10, 2006 8:16 AM To: Azinger, Marla Cc: Christopher Morrow; Divins, David; ppml at arin.net Subject: Re: [ppml] Privacy of Reassignment Information Businesses are people too ;) Are you against "Private Business" with zipcode and admin, noc, etc contact info? Aaron On Mon, Apr 10, 2006 at 08:11:47AM -0700, Azinger, Marla wrote: > I agree we need policy that gives residential privacy but at the same time supports the "research" community. > > ie Mandatory info is: > > Residential > 23456 > upstream abuse contact info > > or > > Residential > 3V6 (hope I got that right. Not sure if canadian postal starts with number or letter) > upstream abuse contact info > > -----Original Message----- > From: Aaron Hughes [mailto:aaronh at bind.com] > Sent: Monday, April 10, 2006 8:03 AM > To: Azinger, Marla > Cc: Christopher Morrow; Divins, David; ppml at arin.net > Subject: Re: [ppml] Privacy of Reassignment Information > > > Marla, agreed. > > The current methodology is simply to lie, so while several people may have issues with protecting this data, we need to find a way to create a policy to allow for this privacy in order to get accurate data imho. > > Aaron > > On Mon, Apr 10, 2006 at 07:56:34AM -0700, Azinger, Marla wrote: > > I'm not sure if I interpreted Davids question correctly. However, RWHOIS does not permit Privacy that isnt allowed on ARIN WHOIS. The information on RWHOIS should be identical to what would be on ARIN WHOIS. > > > > Marla > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > > Christopher Morrow > > Sent: Monday, April 10, 2006 7:42 AM > > To: Divins, David > > Cc: ppml at arin.net > > Subject: Re: [ppml] Privacy of Reassignment Information > > > > > > On 4/7/06, Divins, David wrote: > > > All, > > > > > > Provided an ISP, or other direct assignment recipient, supplies valid > > > and responsive (24x7) Abuse, NOC, and other pertinent contact > > > information, a reassignment should be allowed to remain private. > > > > > > This has been discussed before and abandoned > > > (http://www.arin.net/policy/proposals/2004_6.html). However, I feel > > > this issue needs to be raised again as it is more important than ever. > > > > > > There are ample valid reasons for a reassignment to remain private. > > > > > > ISP's may not want their customers to be mined via a public service. > > > Many companies only use their assignment for private business exchanges > > > and do not want a public vector into their block. HIPAA clearing > > > facilities, banking exchanges, procurement systems are all example of > > > viable private reassignments. > > > > > > > I might have missed something in the policy and this note... but, > > doesn't the ability to use rwhois and limit access to 'arin' solve > > this privacy issue as well? With this capability perhaps the need to > > construct policy around privacy of information isn't necessary? > > > > -Chris > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > -- > > 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/ -- 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 dsd at servervault.com Mon Apr 10 11:24:17 2006 From: dsd at servervault.com (Divins, David) Date: Mon, 10 Apr 2006 11:24:17 -0400 Subject: [ppml] Privacy of Reassignment Information Message-ID: Just to repeat, we are talking about corporate privacy: I would be happy with: Private Company 20166 UpStrean Abuse contact info -dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 -----Original Message----- From: Azinger, Marla [mailto:marla_azinger at eli.net] Sent: Monday, April 10, 2006 11:12 AM To: Aaron Hughes Cc: Christopher Morrow; Divins, David; ppml at arin.net Subject: RE: [ppml] Privacy of Reassignment Information I agree we need policy that gives residential privacy but at the same time supports the "research" community. ie Mandatory info is: Residential 23456 upstream abuse contact info or Residential 3V6 (hope I got that right. Not sure if canadian postal starts with number or letter) upstream abuse contact info -----Original Message----- From: Aaron Hughes [mailto:aaronh at bind.com] Sent: Monday, April 10, 2006 8:03 AM To: Azinger, Marla Cc: Christopher Morrow; Divins, David; ppml at arin.net Subject: Re: [ppml] Privacy of Reassignment Information Marla, agreed. The current methodology is simply to lie, so while several people may have issues with protecting this data, we need to find a way to create a policy to allow for this privacy in order to get accurate data imho. Aaron On Mon, Apr 10, 2006 at 07:56:34AM -0700, Azinger, Marla wrote: > I'm not sure if I interpreted Davids question correctly. However, RWHOIS does not permit Privacy that isnt allowed on ARIN WHOIS. The information on RWHOIS should be identical to what would be on ARIN WHOIS. > > Marla > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Christopher Morrow > Sent: Monday, April 10, 2006 7:42 AM > To: Divins, David > Cc: ppml at arin.net > Subject: Re: [ppml] Privacy of Reassignment Information > > > On 4/7/06, Divins, David wrote: > > All, > > > > Provided an ISP, or other direct assignment recipient, supplies > > valid and responsive (24x7) Abuse, NOC, and other pertinent contact > > information, a reassignment should be allowed to remain private. > > > > This has been discussed before and abandoned > > (http://www.arin.net/policy/proposals/2004_6.html). However, I feel > > this issue needs to be raised again as it is more important than ever. > > > > There are ample valid reasons for a reassignment to remain private. > > > > ISP's may not want their customers to be mined via a public service. > > Many companies only use their assignment for private business > > exchanges and do not want a public vector into their block. HIPAA > > clearing facilities, banking exchanges, procurement systems are all > > example of viable private reassignments. > > > > I might have missed something in the policy and this note... but, > doesn't the ability to use rwhois and limit access to 'arin' solve > this privacy issue as well? With this capability perhaps the need to > construct policy around privacy of information isn't necessary? > > -Chris > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- 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 william at elan.net Mon Apr 10 11:24:07 2006 From: william at elan.net (william(at)elan.net) Date: Mon, 10 Apr 2006 08:24:07 -0700 (PDT) Subject: [ppml] Privacy of Reassignment Information In-Reply-To: References: Message-ID: I would not accept this. But would you accept if you were not required to publish info at all for blocks quite a bit larger then current /29 (i.e. raise publication limits so that most small business customers do not have to be listed)? On Mon, 10 Apr 2006, Divins, David wrote: > Just to repeat, we are talking about corporate privacy: > > I would be happy with: > > Private Company > 20166 > UpStrean Abuse contact info > > -dsd > > David Divins > Principal Engineer > ServerVault Corp. > (703) 652-5955 > -----Original Message----- > From: Azinger, Marla [mailto:marla_azinger at eli.net] > Sent: Monday, April 10, 2006 11:12 AM > To: Aaron Hughes > Cc: Christopher Morrow; Divins, David; ppml at arin.net > Subject: RE: [ppml] Privacy of Reassignment Information > > I agree we need policy that gives residential privacy but at the same > time supports the "research" community. > > ie Mandatory info is: > > Residential > 23456 > upstream abuse contact info > > or > > Residential > 3V6 (hope I got that right. Not sure if canadian postal starts with > number or letter) upstream abuse contact info > > -----Original Message----- > From: Aaron Hughes [mailto:aaronh at bind.com] > Sent: Monday, April 10, 2006 8:03 AM > To: Azinger, Marla > Cc: Christopher Morrow; Divins, David; ppml at arin.net > Subject: Re: [ppml] Privacy of Reassignment Information > > > Marla, agreed. > > The current methodology is simply to lie, so while several people may > have issues with protecting this data, we need to find a way to create a > policy to allow for this privacy in order to get accurate data imho. > > Aaron > > On Mon, Apr 10, 2006 at 07:56:34AM -0700, Azinger, Marla wrote: >> I'm not sure if I interpreted Davids question correctly. However, > RWHOIS does not permit Privacy that isnt allowed on ARIN WHOIS. The > information on RWHOIS should be identical to what would be on ARIN > WHOIS. >> >> Marla >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > >> Christopher Morrow >> Sent: Monday, April 10, 2006 7:42 AM >> To: Divins, David >> Cc: ppml at arin.net >> Subject: Re: [ppml] Privacy of Reassignment Information >> >> >> On 4/7/06, Divins, David wrote: >>> All, >>> >>> Provided an ISP, or other direct assignment recipient, supplies >>> valid and responsive (24x7) Abuse, NOC, and other pertinent contact >>> information, a reassignment should be allowed to remain private. >>> >>> This has been discussed before and abandoned >>> (http://www.arin.net/policy/proposals/2004_6.html). However, I feel > >>> this issue needs to be raised again as it is more important than > ever. >>> >>> There are ample valid reasons for a reassignment to remain private. >>> >>> ISP's may not want their customers to be mined via a public service. >>> Many companies only use their assignment for private business >>> exchanges and do not want a public vector into their block. HIPAA >>> clearing facilities, banking exchanges, procurement systems are all >>> example of viable private reassignments. >>> >> >> I might have missed something in the policy and this note... but, >> doesn't the ability to use rwhois and limit access to 'arin' solve >> this privacy issue as well? With this capability perhaps the need to >> construct policy around privacy of information isn't necessary? >> >> -Chris >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Mon Apr 10 11:25:35 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Apr 2006 11:25:35 -0400 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <20060410151542.GE17436@user1.bind.com> References: <10ECB7F03C568F48B9213EF9E7F790D202100CFD@wava00s2ke2k01.corp.pvt > <20060410151542.GE17436@user1.bind.com> Message-ID: <00F8E8478174C1B565DC730F@host139-198.arin-xvii.arin.net> No, they aren't. Businesses are made up largely of people, but, they are not people. The theory that corporations have rights under the constitution is a legal fallacy. One of the biggest mistakes made in legal precedent in this country was the determination that corporations have a right to free speech and (virtually unlimited) participation in the political process. Owen --On April 10, 2006 11:15:42 AM -0400 Aaron Hughes wrote: > Businesses are people too ;) > -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From ppml at rsuc.gweep.net Mon Apr 10 11:27:12 2006 From: ppml at rsuc.gweep.net (Joe Provo) Date: Mon, 10 Apr 2006 11:27:12 -0400 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: References: Message-ID: <20060410152712.GA94306@gweep.net> On Mon, Apr 10, 2006 at 11:24:17AM -0400, Divins, David wrote: > Just to repeat, we are talking about corporate privacy: Uh, why? This is an impediment to growth, as the business can't justify their existing space usage to graduate to more without involving potentially muliple humans at multiple ISPs. The problem of inappropriate use of WHOIS data is not solved by obfuscating some of the data. The bad guys hide. The good guys operate transparently. That's served us all collectiveely very well over the years. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From randy at psg.com Mon Apr 10 17:29:56 2006 From: randy at psg.com (Randy Bush) Date: Mon, 10 Apr 2006 11:29:56 -1000 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <20060410152712.GA94306@gweep.net> References: <20060410152712.GA94306@gweep.net> Message-ID: <443ACE54.5070508@psg.com> > The bad guys hide. The good guys operate transparently. That's > served us all collectiveely very well over the years. so we should allow opacity so we can tell the bad guys because they use it? :-)/2 randy From marla_azinger at eli.net Mon Apr 10 11:29:35 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Mon, 10 Apr 2006 08:29:35 -0700 Subject: [ppml] Privacy of Reassignment Information Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A500@wava00s2ke2k01.corp.pvt> no. I was talking about residential. sorry -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Divins, David Sent: Monday, April 10, 2006 8:24 AM To: ppml at arin.net Subject: Re: [ppml] Privacy of Reassignment Information Just to repeat, we are talking about corporate privacy: I would be happy with: Private Company 20166 UpStrean Abuse contact info -dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 -----Original Message----- From: Azinger, Marla [mailto:marla_azinger at eli.net] Sent: Monday, April 10, 2006 11:12 AM To: Aaron Hughes Cc: Christopher Morrow; Divins, David; ppml at arin.net Subject: RE: [ppml] Privacy of Reassignment Information I agree we need policy that gives residential privacy but at the same time supports the "research" community. ie Mandatory info is: Residential 23456 upstream abuse contact info or Residential 3V6 (hope I got that right. Not sure if canadian postal starts with number or letter) upstream abuse contact info -----Original Message----- From: Aaron Hughes [mailto:aaronh at bind.com] Sent: Monday, April 10, 2006 8:03 AM To: Azinger, Marla Cc: Christopher Morrow; Divins, David; ppml at arin.net Subject: Re: [ppml] Privacy of Reassignment Information Marla, agreed. The current methodology is simply to lie, so while several people may have issues with protecting this data, we need to find a way to create a policy to allow for this privacy in order to get accurate data imho. Aaron On Mon, Apr 10, 2006 at 07:56:34AM -0700, Azinger, Marla wrote: > I'm not sure if I interpreted Davids question correctly. However, RWHOIS does not permit Privacy that isnt allowed on ARIN WHOIS. The information on RWHOIS should be identical to what would be on ARIN WHOIS. > > Marla > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Christopher Morrow > Sent: Monday, April 10, 2006 7:42 AM > To: Divins, David > Cc: ppml at arin.net > Subject: Re: [ppml] Privacy of Reassignment Information > > > On 4/7/06, Divins, David wrote: > > All, > > > > Provided an ISP, or other direct assignment recipient, supplies > > valid and responsive (24x7) Abuse, NOC, and other pertinent contact > > information, a reassignment should be allowed to remain private. > > > > This has been discussed before and abandoned > > (http://www.arin.net/policy/proposals/2004_6.html). However, I feel > > this issue needs to be raised again as it is more important than ever. > > > > There are ample valid reasons for a reassignment to remain private. > > > > ISP's may not want their customers to be mined via a public service. > > Many companies only use their assignment for private business > > exchanges and do not want a public vector into their block. HIPAA > > clearing facilities, banking exchanges, procurement systems are all > > example of viable private reassignments. > > > > I might have missed something in the policy and this note... but, > doesn't the ability to use rwhois and limit access to 'arin' solve > this privacy issue as well? With this capability perhaps the need to > construct policy around privacy of information isn't necessary? > > -Chris > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- 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/ _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From marla_azinger at eli.net Mon Apr 10 11:31:05 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Mon, 10 Apr 2006 08:31:05 -0700 Subject: [ppml] Privacy of Reassignment Information Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A501@wava00s2ke2k01.corp.pvt> sorry. again I was talking about Residential only. I strongly oppose private rules for corprate. Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of william(at)elan.net Sent: Monday, April 10, 2006 8:24 AM To: Divins, David Cc: ppml at arin.net Subject: Re: [ppml] Privacy of Reassignment Information I would not accept this. But would you accept if you were not required to publish info at all for blocks quite a bit larger then current /29 (i.e. raise publication limits so that most small business customers do not have to be listed)? On Mon, 10 Apr 2006, Divins, David wrote: > Just to repeat, we are talking about corporate privacy: > > I would be happy with: > > Private Company > 20166 > UpStrean Abuse contact info > > -dsd > > David Divins > Principal Engineer > ServerVault Corp. > (703) 652-5955 > -----Original Message----- > From: Azinger, Marla [mailto:marla_azinger at eli.net] > Sent: Monday, April 10, 2006 11:12 AM > To: Aaron Hughes > Cc: Christopher Morrow; Divins, David; ppml at arin.net > Subject: RE: [ppml] Privacy of Reassignment Information > > I agree we need policy that gives residential privacy but at the same > time supports the "research" community. > > ie Mandatory info is: > > Residential > 23456 > upstream abuse contact info > > or > > Residential > 3V6 (hope I got that right. Not sure if canadian postal starts with > number or letter) upstream abuse contact info > > -----Original Message----- > From: Aaron Hughes [mailto:aaronh at bind.com] > Sent: Monday, April 10, 2006 8:03 AM > To: Azinger, Marla > Cc: Christopher Morrow; Divins, David; ppml at arin.net > Subject: Re: [ppml] Privacy of Reassignment Information > > > Marla, agreed. > > The current methodology is simply to lie, so while several people may > have issues with protecting this data, we need to find a way to create a > policy to allow for this privacy in order to get accurate data imho. > > Aaron > > On Mon, Apr 10, 2006 at 07:56:34AM -0700, Azinger, Marla wrote: >> I'm not sure if I interpreted Davids question correctly. However, > RWHOIS does not permit Privacy that isnt allowed on ARIN WHOIS. The > information on RWHOIS should be identical to what would be on ARIN > WHOIS. >> >> Marla >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > >> Christopher Morrow >> Sent: Monday, April 10, 2006 7:42 AM >> To: Divins, David >> Cc: ppml at arin.net >> Subject: Re: [ppml] Privacy of Reassignment Information >> >> >> On 4/7/06, Divins, David wrote: >>> All, >>> >>> Provided an ISP, or other direct assignment recipient, supplies >>> valid and responsive (24x7) Abuse, NOC, and other pertinent contact >>> information, a reassignment should be allowed to remain private. >>> >>> This has been discussed before and abandoned >>> (http://www.arin.net/policy/proposals/2004_6.html). However, I feel > >>> this issue needs to be raised again as it is more important than > ever. >>> >>> There are ample valid reasons for a reassignment to remain private. >>> >>> ISP's may not want their customers to be mined via a public service. >>> Many companies only use their assignment for private business >>> exchanges and do not want a public vector into their block. HIPAA >>> clearing facilities, banking exchanges, procurement systems are all >>> example of viable private reassignments. >>> >> >> I might have missed something in the policy and this note... but, >> doesn't the ability to use rwhois and limit access to 'arin' solve >> this privacy issue as well? With this capability perhaps the need to >> construct policy around privacy of information isn't necessary? >> >> -Chris >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From jb at jbacher.com Mon Apr 10 11:38:12 2006 From: jb at jbacher.com (J Bacher) Date: Mon, 10 Apr 2006 10:38:12 -0500 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D20295A4FF@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D20295A4FF@wava00s2ke2k01.corp.pvt> Message-ID: <443A7BE4.9000806@jbacher.com> Azinger, Marla wrote: > Totally I disagree with Marla. Any residential assignment, regardless of personal or business use, should be entitled to a private listing. > -----Original Message----- > From: Aaron Hughes [mailto:aaronh at bind.com] > Sent: Monday, April 10, 2006 8:16 AM > To: Azinger, Marla > Cc: Christopher Morrow; Divins, David; ppml at arin.net > Subject: Re: [ppml] Privacy of Reassignment Information > > > Businesses are people too ;) > > Are you against "Private Business" with zipcode and admin, noc, etc contact info? From aaronh at bind.com Mon Apr 10 11:40:41 2006 From: aaronh at bind.com (Aaron Hughes) Date: Mon, 10 Apr 2006 11:40:41 -0400 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <443A7BE4.9000806@jbacher.com> References: <10ECB7F03C568F48B9213EF9E7F790D20295A4FF@wava00s2ke2k01.corp.pvt> <443A7BE4.9000806@jbacher.com> Message-ID: <20060410154041.GF17436@user1.bind.com> Sorry Jan, The intent was only to focus on business for the purpose of this proposal. Dave, Can you clarify the subject perhaps? Cheers. Aaron On Mon, Apr 10, 2006 at 10:38:12AM -0500, J Bacher wrote: > Azinger, Marla wrote: > > Totally > > I disagree with Marla. Any residential assignment, regardless of > personal or business use, should be entitled to a private listing. > > > > -----Original Message----- > > From: Aaron Hughes [mailto:aaronh at bind.com] > > Sent: Monday, April 10, 2006 8:16 AM > > To: Azinger, Marla > > Cc: Christopher Morrow; Divins, David; ppml at arin.net > > Subject: Re: [ppml] Privacy of Reassignment Information > > > > > > Businesses are people too ;) > > > > Are you against "Private Business" with zipcode and admin, noc, etc contact info? > > _______________________________________________ > 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 steve at blighty.com Mon Apr 10 11:41:45 2006 From: steve at blighty.com (Steve Atkins) Date: Mon, 10 Apr 2006 08:41:45 -0700 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <443A7BE4.9000806@jbacher.com> References: <10ECB7F03C568F48B9213EF9E7F790D20295A4FF@wava00s2ke2k01.corp.pvt> <443A7BE4.9000806@jbacher.com> Message-ID: <7B9C8B57-EB53-4AF4-B8DD-D9E813A17465@blighty.com> On Apr 10, 2006, at 8:38 AM, J Bacher wrote: > Azinger, Marla wrote: >> Totally > > I disagree with Marla. Any residential assignment, regardless of > personal or business use, should be entitled to a private listing. Most governments require publication of business addresses, even if those are in private residences. Has that caused problems? Cheers, Steve From marla_azinger at eli.net Mon Apr 10 11:50:41 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Mon, 10 Apr 2006 08:50:41 -0700 Subject: [ppml] Privacy of Reassignment Information Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A502@wava00s2ke2k01.corp.pvt> not that I am aware of. You can find the addresses on the BBB even...I think. Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Steve Atkins Sent: Monday, April 10, 2006 8:42 AM To: ppml at arin.net Subject: Re: [ppml] Privacy of Reassignment Information On Apr 10, 2006, at 8:38 AM, J Bacher wrote: > Azinger, Marla wrote: >> Totally > > I disagree with Marla. Any residential assignment, regardless of > personal or business use, should be entitled to a private listing. Most governments require publication of business addresses, even if those are in private residences. Has that caused problems? Cheers, Steve _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From bicknell at ufp.org Mon Apr 10 12:00:36 2006 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 10 Apr 2006 12:00:36 -0400 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <7B9C8B57-EB53-4AF4-B8DD-D9E813A17465@blighty.com> References: <10ECB7F03C568F48B9213EF9E7F790D20295A4FF@wava00s2ke2k01.corp.pvt> <443A7BE4.9000806@jbacher.com> <7B9C8B57-EB53-4AF4-B8DD-D9E813A17465@blighty.com> Message-ID: <20060410160035.GA61206@ussenterprise.ufp.org> In a message written on Mon, Apr 10, 2006 at 08:41:45AM -0700, Steve Atkins wrote: > Most governments require publication of business addresses, even > if those are in private residences. Has that caused problems? I may be wrong, but I believe they only require the "Primary" business address. That is, if you have 5 offices in town you're only required to list one as the primary location with your corporate paperwork, the other 4 can be "anonymous" from that perspective. -- 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 jb at jbacher.com Mon Apr 10 12:03:32 2006 From: jb at jbacher.com (J Bacher) Date: Mon, 10 Apr 2006 11:03:32 -0500 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <20060410154041.GF17436@user1.bind.com> References: <10ECB7F03C568F48B9213EF9E7F790D20295A4FF@wava00s2ke2k01.corp.pvt> <443A7BE4.9000806@jbacher.com> <20060410154041.GF17436@user1.bind.com> Message-ID: <443A81D4.1060104@jbacher.com> Aaron Hughes wrote: > Sorry Jan, > > The intent was only to focus on business for the purpose of this proposal. Understood. Perhaps it would be better to specify it as "non-residential". Nits, you know :) From marla_azinger at eli.net Mon Apr 10 12:02:35 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Mon, 10 Apr 2006 09:02:35 -0700 Subject: [ppml] Privacy of Reassignment Information Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A503@wava00s2ke2k01.corp.pvt> I think that is right. But they do require what I would call a "main/or flagstaff" office address. -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Leo Bicknell Sent: Monday, April 10, 2006 9:01 AM To: ppml at arin.net Subject: Re: [ppml] Privacy of Reassignment Information In a message written on Mon, Apr 10, 2006 at 08:41:45AM -0700, Steve Atkins wrote: > Most governments require publication of business addresses, even > if those are in private residences. Has that caused problems? I may be wrong, but I believe they only require the "Primary" business address. That is, if you have 5 offices in town you're only required to list one as the primary location with your corporate paperwork, the other 4 can be "anonymous" from that perspective. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From jb at jbacher.com Mon Apr 10 12:06:35 2006 From: jb at jbacher.com (J Bacher) Date: Mon, 10 Apr 2006 11:06:35 -0500 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <7B9C8B57-EB53-4AF4-B8DD-D9E813A17465@blighty.com> References: <10ECB7F03C568F48B9213EF9E7F790D20295A4FF@wava00s2ke2k01.corp.pvt> <443A7BE4.9000806@jbacher.com> <7B9C8B57-EB53-4AF4-B8DD-D9E813A17465@blighty.com> Message-ID: <443A828B.3070107@jbacher.com> >>> Totally >> I disagree with Marla. Any residential assignment, regardless of >> personal or business use, should be entitled to a private listing. > > Most governments require publication of business addresses, even > if those are in private residences. Has that caused problems? I am not incorporated in any form. From dsd at servervault.com Mon Apr 10 12:17:09 2006 From: dsd at servervault.com (Divins, David) Date: Mon, 10 Apr 2006 12:17:09 -0400 Subject: [ppml] Privacy of corporate reassignment information in public whois Message-ID: This is an attempt to rename this thread a little more accurately. Also, remember that reassignments are done not just for transit ISP customers but also for hosting customers. For the majority of the hosted customers, they may never get a direct allocation from ARIN. In this scenario, the hosting provider needs to reassign this address space as used by a customer to justify its own address expansion requests. I have been informed that reassigning to the Hosting Provider with its abuse/noc contact and with description "Hosted Customer A" is not acceptable. Just some more thoughts. -dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 From william at elan.net Mon Apr 10 12:13:38 2006 From: william at elan.net (william(at)elan.net) Date: Mon, 10 Apr 2006 09:13:38 -0700 (PDT) Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <20060410160035.GA61206@ussenterprise.ufp.org> References: <10ECB7F03C568F48B9213EF9E7F790D20295A4FF@wava00s2ke2k01.corp.pvt> <443A7BE4.9000806@jbacher.com> <7B9C8B57-EB53-4AF4-B8DD-D9E813A17465@blighty.com> <20060410160035.GA61206@ussenterprise.ufp.org> Message-ID: On Mon, 10 Apr 2006, Leo Bicknell wrote: > In a message written on Mon, Apr 10, 2006 at 08:41:45AM -0700, Steve Atkins wrote: >> Most governments require publication of business addresses, even >> if those are in private residences. Has that caused problems? > > I may be wrong, but I believe they only require the "Primary" > business address. That is, if you have 5 offices in town you're > only required to list one as the primary location with your corporate > paperwork, the other 4 can be "anonymous" from that perspective. That is partially correct when those other addresses are residential. If they are commercial, the records will end up available as you have to get business license for each office. And in majority of localities you have to get business license for each residential location as well if you're using it for business purposes. Similarly you usually have to get business insurance for both residential and business locations and in some localities this insurance is public information upon special requests. Now in practice of course many small businesses run of their residence will not fully comply with all the regulations (and almost always get away with that), but that is another matter. -- William Leibzon Elan Networks william at elan.net From dsd at servervault.com Mon Apr 10 12:25:26 2006 From: dsd at servervault.com (Divins, David) Date: Mon, 10 Apr 2006 12:25:26 -0400 Subject: [ppml] Privacy of Non-Residential Reassignments in Public Whois Message-ID: Due to popular demand....Attempt number 3 at an accurate Subject :-) David Divins Principal Engineer ServerVault Corp. (703) 652-5955 From jordi.palet at consulintel.es Mon Apr 10 12:22:41 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 10 Apr 2006 12:22:41 -0400 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <7B9C8B57-EB53-4AF4-B8DD-D9E813A17465@blighty.com> Message-ID: Hi all, In the LACNIC policy mailing list we had been in that discussion several times the last months (just to make it clear, here I'm talking for myself) and I think we tend to agree that may be not all the data that we have right now is actually required. I've been also involved in a lot of research on this matter and actually published a non-for-profit book, in English and Spanish, with studied the legal implications for IPv6, in the European regulations, but actually compared everything with IPv4 also (so is applicable to IP in general, I will say). The book is available in PDF format at http://www.ipv6tf.org/news/newsroom.php?id=1260. I think is clear to everybody, and no need for a new debate on that, that privacy for residential customers is a must and appropriate policy is already there in some of the regions. Is also clear that we want and need certain degree of accountability, specially for the RIRs to make sure that they aren't being cheated with actual utilization figures. However, the current policy may enforce to some people to actually fill in with ghost or inaccurate data, because they are requested to keep the privacy by their customers (even if not residential). But is somebody at the registries actually checking all this data ? I guess not ... So the goal of public databases such as whois for accountability is not working out. In Spain (I think same as the rest of EU) you've the choice, even if you are a company, to request your address, phone, etc., not to be published in the phone books. Of course, this information is available at the merchant registries, which are public, but often can only be consulted in the merchant registry buildings (I guess this could change in the future, of course). We tend to use this data for NOC/abuse purposes, but may be not all the data is needed for that, or even more, there are lots of business which don't run by themselves the NOC/abuse service and they rely in the upstream provider, third parties, etc. So I think we need to review the reason for having ALL this data openly available, and instead allow the business to decide if they want to have real data (which may be not useful and even be false) or just provide the contact points that they decide. Also, how much of this data is actually needed for NOC/abuse, or if it make sense to have a contact from the ISP or even the RIR to call in in case of any incident (when the data is not available publicly because or corporate privacy policy decision, etc.). Regards, Jordi > De: Steve Atkins > Responder a: > Fecha: Mon, 10 Apr 2006 08:41:45 -0700 > Para: "ppml at arin.net" > Asunto: Re: [ppml] Privacy of Reassignment Information > > > On Apr 10, 2006, at 8:38 AM, J Bacher wrote: > >> Azinger, Marla wrote: >>> Totally >> >> I disagree with Marla. Any residential assignment, regardless of >> personal or business use, should be entitled to a private listing. > > Most governments require publication of business addresses, even > if those are in private residences. Has that caused problems? > > Cheers, > Steve > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From tvest at pch.net Mon Apr 10 13:27:43 2006 From: tvest at pch.net (Tom Vest) Date: Mon, 10 Apr 2006 13:27:43 -0400 Subject: [ppml] [arin-discuss] Privacy of Reassignment Information In-Reply-To: <860-SnapperMsgF653DE21C0603A50@[10.199.247.19]> References: <860-SnapperMsgF653DE21C0603A50@[10.199.247.19]> Message-ID: <73366B37-91F8-4E03-B429-08436CCC0662@pch.net> If the information can be legitimately obscured, then it is only a matter of time before the anonymity will be abused by unscrupulous people. I think it would be prudent to take a letter from other "governance" discussions, and strongly resist the temptation to combat "higher level" abuses by imposing the enforcement burden on "lower level" operations/administrative structures. ARIN and the RIRs are vested with responsibility for maintaining records for number resources held in public trust. If the records are abused, the specific abuses and abusers should be targeted -- even if this is more difficult -- rather than taking the easy route of attacking the underlying systems. Tom On Apr 10, 2006, at 12:37 PM, G.Hiscott wrote: > if the information is available, then it is only a matter of time > before it > will be abused for marketing purposes by unscrupolous sales people. > > > ___ > www.keyconnect.com > > ...... Original Message ....... > On Mon, 10 Apr 2006 12:23:34 -0400 "Mark Erskine" > > wrote: >> I'll second that! >> >> >> Thanks, >> Mark Erskine >> Host Depot, Inc. >> http://www.HostDepot.com >> Phone: 954.340.3527 >> Fax: 954.340.3539 >> >> >> -----Original Message----- >> From: arin-discuss-bounces at arin.net >> [mailto:arin-discuss-bounces at arin.net] On Behalf Of Barry Dykes >> Sent: Monday, April 10, 2006 12:20 PM >> Cc: ARIN-discuss at arin.net; ppml at arin.net >> Subject: Re: [arin-discuss] Privacy of Reassignment Information >> >> I have to say that I do not agree with making everything public. >> Spam >> and phishing are one thing, but I pay a lot of money to get my >> customers >> and more to keep them. I have no intention of posting that for any >> competitor to browse. >> >> Thanks, >> >> >> Barry A. Dykes >> VP Engineering/Operations >> ViaWest Internet Services >> bdykes at viawest.net >> 303-407-4708 >> >> >> >> >> _______________________________________________ >> ARIN-discuss mailing list >> ARIN-discuss at arin.net >> http://lists.arin.net/mailman/listinfo/arin-discuss >> _______________________________________________ >> ARIN-discuss mailing list >> ARIN-discuss at arin.net >> http://lists.arin.net/mailman/listinfo/arin-discuss >> > > _______________________________________________ > ARIN-discuss mailing list > ARIN-discuss at arin.net > http://lists.arin.net/mailman/listinfo/arin-discuss From owen at delong.com Mon Apr 10 13:52:20 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Apr 2006 13:52:20 -0400 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: <20060410160035.GA61206@ussenterprise.ufp.org> References: <10ECB7F03C568F48B9213EF9E7F790D20295A4FF@wava00s2ke2k01.corp.pvt > <443A7BE4.9000806@jbacher.com> <7B9C8B57-EB53-4AF4-B8DD-D9E813A17465@blighty.com> <20060410160035.GA61206@ussenterprise.ufp.org> Message-ID: <9A1C454BF76EB9C020278E4E@host139-198.arin-xvii.arin.net> > I may be wrong, but I believe they only require the "Primary" > business address. That is, if you have 5 offices in town you're > only required to list one as the primary location with your corporate > paperwork, the other 4 can be "anonymous" from that perspective. Depends... If you are talking about sellers permits, for example, usually they are required to show the location where sales are being conducted. If you are talking about 10K/10Q filings, they usually include only primary address(es). Other types of business have varying requirements, but, it is almost impossible to operate a business legally without having some public record which contains address information for all of your locations. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From andrew.dul at quark.net Mon Apr 10 13:52:29 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Mon, 10 Apr 2006 17:52:29 +0000 Subject: [ppml] PI Assignment Survey Results Message-ID: <20060410175229.23296.qmail@hoster908.com> Here is a copy of the survey results from those who choose to participate. You can also see the results in graphical form here: http://www.quark.net/survey/results.php?sid=28 Andrew ------------------------------------- 1. I support the creation of a IPv6 Provider Independent Address Policy. Strongly Agree - 19 59.38% Agree - 6 18.75% Neither agree nor disagree - 1 3.13% Disagree - 3 9.38% Strongly Disagree - 3 9.38% Total Answers - 32 2. I support an IPv6 PI assignment to any organization which qualifies for an IPv4 assignment. Strongly Agree - 12 36.36% Agree - 10 30.30% Neither agree nor disagree - 1 3.03% Disagree - 6 18.18% Strongly Disagree - 4 12.12% Total Answers - 33 3. I support an IPv6 PI policy which requires other criteria. (Other than any IPv4 assignment) Strongly Agree - 7 21.21% Agree - 11 33.33% Neither agree nor disagree - 8 24.24% Disagree - 5 15.15% Strongly Disagree - 2 6.06% Total Answers - 33 4. Should the requirement of "end-site" as defined in the current IPv6 policy be a requirement for a PI assignment? Yes - 10 33.33% No - 20 66.67% Total Answers - 30 5. I support the requirement that an organization must be multihomed to qualify for an IPv6 PI assignment. Agree - 22 66.67% Neither agree nor disagree - 4 12.12% Disagree - 7 21.21% Total Answers - 33 6. I support the requirement that an organization must have a current IPv4 assignment to qualify for an IPv6 PI assignment. Agree - 5 15.15% Neither agree nor disagree - 15 45.45% Disagree - 13 39.39% Total Answers - 33 7. What size of IPv4 assignment should the organization have to qualify for an IPv6 PI assignment? /24 - 2 6.45% /23 - 0 0.00% /22 - 6 19.35% /21 - 1 3.23% /20 - 3 9.68% /19 - 4 12.90% /18 - 0 0.00% /17 - 0 0.00% /16 - 5 16.13% No Preference - 10 32.26% Total Answers - 31 8. I support the requirement to assign IPv6 PI address space from a seperate super block. Agree - 19 59.38% Neither agree nor disagree - 9 28.13% Disagree - 4 12.50% Total Answers - 32 9. I support a minimum size for an IPv6 PI address assignment. Agree - 26 78.79% Neither agree nor disagree - 4 12.12% Disagree - 3 9.09% Total Answers - 33 10. What should be the minimum assignment size? /40 - 4 12.50% /44 - 1 3.13% /48 - 20 62.50% /64 - 2 6.25% No Preference - 5 15.63% Total Answers - 32 11. I support a maximum assignment size. Agree - 8 25.81% Neither agree nor disagree - 10 32.26% Disagree - 13 41.94% Total Answers - 31 12. What should be the maximum assignment size? /32 - 2 8.33% /36 - 1 4.17% /40 - 6 25.00% /48 - 3 12.50% No Preference - 12 50.00% Total Answers - 24 13. I support the requirement to specify a reserved block in an IPv6 PI address policy. Agree - 13 40.63% Neither agree nor disagree - 12 37.50% Disagree - 7 21.88% Total Answers - 32 14. What should be the reserved block size? /32 - 5 17.24% /44 - 7 24.14% /46 - 1 3.45% No Preference - 16 55.17% Total Answers - 29 15. I support the assignment of additional /48 subnets to organizations with multiple assigned ASNs. Agree - 18 54.55% Neither agree nor disagree - 8 24.24% Disagree - 7 21.21% Total Answers - 33 16. I support the assignment of multiple /48s per organization. Agree - 19 57.58% Neither agree nor disagree - 8 24.24% Disagree - 6 18.18% Total Answers - 33 17. Do you support ARIN Policy Proposal 2005-1 as currently written? Yes - 18 56.25% No - 14 43.75% Total Answers - 32 18. Do you support ARIN Policy Proposal 2006-4 as currently written? Yes - 14 43.75% No - 18 56.25% Total Answers - 32 20. Which of the following best describes your affiliation? Internet Service Provider - 14 43.75% Equipment Vendor - 1 3.13% Network Operator - 2 6.25% Education & Research - 1 3.13% Software Vendor - 1 3.13% Large Enterprise - 5 15.63% Small Enterprise - 1 3.13% Government - 0 0.00% Content Provider - 3 9.38% Non-Profit Organization - 1 3.13% Consultant - 2 6.25% Internet User - 0 0.00% Other - 1 3.13% Total Answers - 32 From christopher.morrow at gmail.com Mon Apr 10 15:13:06 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 10 Apr 2006 15:13:06 -0400 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: References: Message-ID: <75cb24520604101213h6fd50361w6bdbad20fd9d4951@mail.gmail.com> On 4/10/06, Divins, David wrote: > Chris, > > According to ARIN policy an RWHOIS server must be always on and be able > to be queried by the public. It may not be firewalled to just allow > ARIN access :-( > crap, I searched the policy as well for this and couldn't locate it either, could Level-3 take notice of this fact and not filter their rwhois server? [wuser98-league:~] me% telnet rwhois.level3.net 4321 Trying 209.244.1.179... :( oh well, I thought it might have been a simple way around the problem, no such luck. -chris From alh-ietf at tndh.net Mon Apr 10 15:33:00 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 10 Apr 2006 12:33:00 -0700 Subject: [ppml] PI policy discussion Message-ID: <176601c65cd5$9462a500$de79df0a@tndh.net> The primary objection to PI appears to be the presumption of long term deaggregation. If the space used for PI assignments has structure it is conceivable that service providers not directly involved at a level of the structure could ignore the detail through aggregation. This requires a little forethought in terms of laying out space. It doesn't require that we do anything long term, it just creates the potential to mitigate the concern about perpetual deaggregates. Tony From weiler at tislabs.com Mon Apr 10 15:27:34 2006 From: weiler at tislabs.com (Sam Weiler) Date: Mon, 10 Apr 2006 15:27:34 -0400 (EDT) Subject: [ppml] Matching NRPM sections to policies In-Reply-To: <20051028135230.49BF21FF38@mercury.arin.net> References: <20051028135230.49BF21FF38@mercury.arin.net> Message-ID: What (if anything) became of this suggestion? I haven't noticed any changes in the NRPM or policy archive -- is any work happening behind the scenes? -- Sam On Fri, 28 Oct 2005, Ray Plzak wrote: > We will look at doing this. I don't know what the level of effort is to do > this. That and of course other tasks will dictate if and when we can get > this done. > > Ray > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> Samuel Weiler >> Sent: Thursday, October 27, 2005 6:18 PM >> To: ppml at arin.net >> Subject: [ppml] Matching NRPM sections to policies >> >> I'd like to see ARIN go through the (wonderful) NRPM and 1) add more >> cross-references to the policies as adopted, much as a code of >> regulations may refer back to the enacting legislation and 2) add >> complete forward citations from the policy archive into the NRPM. >> Will the staff do that? >> >> For example: >> >> Section 6.5.5.1 cites the Residential Customer Privacy by number >> (2003-3), but the corresponding section about v4, 4.2.3.7.6, doesn't >> mention the policy number. Similarly, section 3.2 makes reference to >> this policy without citing it by number and perhaps making some errors >> in transcription (per the other thread). >> >> In the policy archive, 2003-3 mentions 4.2.3.7.6 as the section where >> the adopted policy was recorded, but does not mention the other two >> sections. >> >> -- Sam From sleibrand at internap.com Mon Apr 10 15:45:06 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 10 Apr 2006 15:45:06 -0400 (EDT) Subject: [ppml] PI policy discussion In-Reply-To: <176601c65cd5$9462a500$de79df0a@tndh.net> References: <176601c65cd5$9462a500$de79df0a@tndh.net> Message-ID: Tony, I've been waiting for the existing PI policies to get the go-ahead nod before raising this, but now that that seems to have happened, I was wondering if you, Michael, and anyone else who's interested would like to work with me to try putting together a policy proposal to address this. Specifically, I'd like such a proposal to be relatively simple, but define a way for ARIN to choose PI networks to ease future aggregation. Would you be interested in doing so at this stage? -Scott On 04/10/06 at 12:33pm -0700, Tony Hain wrote: > The primary objection to PI appears to be the presumption of long term > deaggregation. If the space used for PI assignments has structure it is > conceivable that service providers not directly involved at a level of the > structure could ignore the detail through aggregation. This requires a > little forethought in terms of laying out space. It doesn't require that we > do anything long term, it just creates the potential to mitigate the concern > about perpetual deaggregates. > > Tony > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From alh-ietf at tndh.net Mon Apr 10 15:57:59 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 10 Apr 2006 12:57:59 -0700 Subject: [ppml] PI policy discussion In-Reply-To: Message-ID: <17db01c65cd9$119e1830$de79df0a@tndh.net> I would be happy to work on a proposal. Tony > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Monday, April 10, 2006 12:45 PM > To: Tony Hain > Cc: ppml at arin.net; Michael.Dillon at btradianz.com > Subject: Re: [ppml] PI policy discussion > > Tony, > > I've been waiting for the existing PI policies to get the go-ahead nod > before raising this, but now that that seems to have happened, I was > wondering if you, Michael, and anyone else who's interested would like to > work with me to try putting together a policy proposal to address this. > Specifically, I'd like such a proposal to be relatively simple, but define > a way for ARIN to choose PI networks to ease future aggregation. > > Would you be interested in doing so at this stage? > > -Scott > > On 04/10/06 at 12:33pm -0700, Tony Hain wrote: > > > The primary objection to PI appears to be the presumption of long term > > deaggregation. If the space used for PI assignments has structure it is > > conceivable that service providers not directly involved at a level of > the > > structure could ignore the detail through aggregation. This requires a > > little forethought in terms of laying out space. It doesn't require that > we > > do anything long term, it just creates the potential to mitigate the > concern > > about perpetual deaggregates. > > > > Tony > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > From markjr at easydns.com Mon Apr 10 16:09:54 2006 From: markjr at easydns.com (Mark Jeftovic) Date: Mon, 10 Apr 2006 16:09:54 -0400 Subject: [ppml] 4.4.2 Micro-allocations for anycast services Message-ID: <443ABB92.9070504@easydns.com> Re: http://arin.net/policy/proposals/2006_5.html The ammendment to allow micro-allocations for anycast services has come to my attention and I wanted to take a moment to comment on this and express support for this proposal. As a commercial DNS provider, anycast presents a viable method to increase robustness which adds to net stability. At present, the minimum allocation requirements pose an obstacle to smaller to medium DNS providers who want to test and deploy anycast services. DNS providers are increasingly the targets of DDoS attacks. Making anycast deployment more accessible to small-to-medium sized DNS providers enhances net stability in two ways: 1) it provides the chance for targetted providers to better withstand attacks at the time they occur. 2) it allows for additional analysis of attack traffic which can then be used in conjunction with previously collected data to eventually identify and take down the antagonists. Micro-allocations would promote more widespread use of anycast based DNS services and it would not be unrealistic to posit that it would set the stage where larger portions of the 2nd and 3rd level namespace enjoy the same kind redundancy we've become accustomed to at the root. With respect to the specifics of the proposal, I wonder out loud if limiting the test-bed to 16 allocations over 2 years would lead to a type of "landrush" in micro-allocations which may foster the very situation ARIN is attempting to mitigate: unwarranted allocations. If the test-bed cap is limited to 16, interested parties may apply for the allocation despite not being near ready to deploy, simply to have the option to do so at a later date and being fearful of being "locked-out" of the test bed and having to wait 2 years or more for another shot. My recommendation would be to allow the micro-allocations without limit. Would it be possible to require the assignee to demonstrate appropriate use of the address space within a certain timeframe? A "use-it-or-lose it" approach? In any case, I do hope this is adopted. Sincerely, - mark --- Mark Jeftovic Founder & President, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(866) 273-2892 From woody at pch.net Mon Apr 10 16:17:00 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 10 Apr 2006 13:17:00 -0700 (PDT) Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: <443ABB92.9070504@easydns.com> References: <443ABB92.9070504@easydns.com> Message-ID: > Re: http://arin.net/policy/proposals/2006_5.html I'd wholly second Mark's comments. I operate two of the three largest anycast networks in the world, and built three of the four largest. This policy is desperately needed, and should not be limited to sixteen prefixes, since I'll be applying for at least eight of them, for organizations I do engineering for. :-) -Bill From jordi.palet at consulintel.es Mon Apr 10 16:30:38 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 10 Apr 2006 16:30:38 -0400 Subject: [ppml] PI policy discussion In-Reply-To: Message-ID: Hi Scott, I will be interested in working on that. Regards, Jordi > De: Scott Leibrand > Responder a: > Fecha: Mon, 10 Apr 2006 15:45:06 -0400 (EDT) > Para: Tony Hain > CC: "ppml at arin.net" > Asunto: Re: [ppml] PI policy discussion > > Tony, > > I've been waiting for the existing PI policies to get the go-ahead nod > before raising this, but now that that seems to have happened, I was > wondering if you, Michael, and anyone else who's interested would like to > work with me to try putting together a policy proposal to address this. > Specifically, I'd like such a proposal to be relatively simple, but define > a way for ARIN to choose PI networks to ease future aggregation. > > Would you be interested in doing so at this stage? > > -Scott > > On 04/10/06 at 12:33pm -0700, Tony Hain wrote: > >> The primary objection to PI appears to be the presumption of long term >> deaggregation. If the space used for PI assignments has structure it is >> conceivable that service providers not directly involved at a level of the >> structure could ignore the detail through aggregation. This requires a >> little forethought in terms of laying out space. It doesn't require that we >> do anything long term, it just creates the potential to mitigate the concern >> about perpetual deaggregates. >> >> Tony >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From dsd at servervault.com Mon Apr 10 16:59:16 2006 From: dsd at servervault.com (Divins, David) Date: Mon, 10 Apr 2006 16:59:16 -0400 Subject: [ppml] MOVED RE: [arin-discuss] Privacy of Reassignment Information Message-ID: I never said there is a law preventing companies from publishing this data. However, the USA does have very strict privacy laws regarding to HIPPA healthcare information. If HIPPA healthcare clearing system gets SWIPed it may provide a vector. I am here in Montreal at ARINXVII and I have talked to every ISP I can think of. Every one has either directly placed bad info in whois or have nudge, nudge, wink wink told customers directly how to do it. How accurate and useful is this? If you have no requirement for privacy on reassignments, do not use them. However there are some reasons that customers need it. -dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 _____ From: Internet Partners, Inc. Tech Support [mailto:support at ipinc.net] Sent: Monday, April 10, 2006 4:39 PM To: Divins, David; Owen DeLong; ARIN-discuss at arin.net Subject: RE: [arin-discuss] Privacy of Reassignment Information Please cite the privacy law you are referring to that prohibits a company from placing it's name, phone number and role contact information on an IP assignment. I am unaware of any such law. Just because there's ISP's out there who feel that they can ignore the rules and fill in bogus contact information does not mean we should rewrite the system to cater to these people There are always people who regard public trusts as their own personal property, to abuse as they see fit, and to ignore the rules the rest of us have setup, because they feel that somehow they are "special" that because of who they are and what they do that the rules need to be adjusted to suit their own personal agenda. This is called regarding yourself as above the law. If we trade in the mandate for ISP's to place valid, public data for reassignment information into the database, in exchange for some sort of "NDA trade out" as you are advocating, then we may make a small minority happy and make a problem go away, for the time being. Then when the next small minority has a beef with the system we are going to adjust the system to suit them - because after all we did it for the private numbers people. And so on and so on. Eventually the Internet becomes nothing more than what happened in Europe in the Middle Ages with everyone with their own little fiefdom and their own little laws. If an ISP or a company does not like the requirement to disclose who they are, they can simply not connect to the Internet. Nobody is holding a gun to anyone's head and telling them they must be connected to the Internet or else. If they absoluely have to have e-mail, why last I checked UUCP worked just fine and did not require a public IP address. Ted Mittelstaedt NOC Manager Internet Partners, Inc. -----Original Message----- From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net]On Behalf Of Divins, David Sent: Friday, April 07, 2006 10:26 PM To: Owen DeLong; ARIN-discuss at arin.net Subject: Re: [arin-discuss] Privacy of Reassignment Information All IP Allocations are done based upon trust. If an ISP just wanted to obscure a reassignment they could simply make up a customer. Allowing ISP's to enter into NDA type status for reassignments and representing these reassignments as private in public servers should provide the registrar with more accurate information-- as that is the basis for the reassignment policy. Additionally, this provides much needed privacy for companies that must adhere to ever more restrictive privacy laws. This allows a valid mechanism. Why is a corporate entities right to privacy any less than an individuals (when it comes to IP space-- and remember not all companies are public)? Why is there a need to know what company owns a block provided there is a valid contact provided? This probably brings the question of how can we ensure a valid contact. Since all assignments are done based on trust, there must be some base assumption that for the most part ISP's act according to ARIN rules-- I am not aware of any ARIN para-military-esque auditing arm that checks ISP corporate accounting against IP assignments to see who skirts the rules. Honestly, I would be content to see a policy that allows an ISP to go full NDA with ARIN and provide reassignment information to ARIN on a private basis. Under this condition, the ISP would need to maintain valid contact (abuse/noc) for all address space it has been assigned and not publicly reassigned. I firmly believe that this issue will not be going away. -dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 _____________________________________________ From: Owen DeLong [ mailto:owen at delong.com] Sent: Friday, April 07, 2006 11:56 PM To: Divins, David; ARIN-discuss at arin.net Subject: Re: [arin-discuss] Privacy of Reassignment Information * PGP Signed by an unknown key: 04/07/2006 at 11:55PM --On April 7, 2006 10:25:11 PM -0400 "Divins, David" wrote: > All, > > Provided an ISP, or other direct assignment recipient, supplies valid > and responsive (24x7) Abuse, NOC, and other pertinent contact > information, a reassignment should be allowed to remain private. > First, a direct assignment recipient cannot reassign, so, this would not apply to a direct assignment recipient. Second, the policy was abandoned fairly recently due to lack of support by the community and lack of consensus to move forward. IP resources are an element of public trust. It is common and widespread practice to disclose as a matter of public record possessory interest in public resources. The public interest in an open and equitable system of resource assignments and allocations overrides ISPs interest in hiding the identities of their customers. > The ability for an ISP to selectively and voluntarily make an assignment > private will still allow ARIN to have accurate reassignment information > as the assignments will be provided to ARIN privately whenever address > utilization must be determined. > ARIN is a stewardship organization. The IP addresses are no more owned by ARIN than by any recipient organization. They are administered by ARIN and the ISPs in the public trust. They are public resources. > The private designation in no way relieves the ISP of its responsibility > to the Internet community. In fact, a private reassignment expands this > responsibility as the ISP actually must take on the responsibility > providing valid 24x7 point of contact. > The community vehemently opposed adding such a requirement to the previous attempt at such a policy. > If an ISP is unable or unwilling to provide a responsive NOC/abuse > contact, then they may not designate any reassignments as private. > How would you propose to prevent ISPs from ignoring this requirement? Owen -- If it wasn't crypto-signed, it probably didn't come from me. * Unknown Key * 0x0FE2AA3D - unknown -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Mon Apr 10 17:19:29 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 10 Apr 2006 17:19:29 -0400 (EDT) Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: References: <443ABB92.9070504@easydns.com> Message-ID: Mark and Bill, I have an unanswered question regarding anycast, namely: why do you need a micro-allocation to do it? We've implemented anycast with a subset of a larger block, and have not run into any problems doing so. I also have yet to hear of anyone else who has seen unreachability problems trying to route a /24 or larger from a larger allocation. Additional comments inline... On 04/10/06 at 4:09pm -0400, Mark Jeftovic wrote: > > Re: http://arin.net/policy/proposals/2006_5.html > > The amendment to allow micro-allocations for anycast services has come > to my attention and I wanted to take a moment to comment on this and > express support for this proposal. > > As a commercial DNS provider, anycast presents a viable method to > increase robustness which adds to net stability. I would agree. > At present, the minimum allocation requirements pose an obstacle to > smaller to medium DNS providers who want to test and deploy anycast > services. Can you elaborate on this? I don't see reachability obstacles, as stated above. What other obstacles are there to using your existing space to do anycast? Thanks, Scott From bmanning at vacation.karoshi.com Mon Apr 10 19:16:34 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 10 Apr 2006 23:16:34 +0000 Subject: [ppml] MOVED RE: [arin-discuss] Privacy of Reassignment Information In-Reply-To: References: Message-ID: <20060410231634.GA2516@vacation.karoshi.com.> er... you talked to me. I've never put bad data into whois, for me or my customers. there are reasons to not put data into whois at all. no data is not bad data. --bill On Mon, Apr 10, 2006 at 04:59:16PM -0400, Divins, David wrote: > I never said there is a law preventing companies from publishing this > data. However, the USA does have very strict privacy laws regarding to > HIPPA healthcare information. If HIPPA healthcare clearing system gets > SWIPed it may provide a vector. > > I am here in Montreal at ARINXVII and I have talked to every ISP I can > think of. Every one has either directly placed bad info in whois or > have nudge, nudge, wink wink told customers directly how to do it. > > How accurate and useful is this? > > If you have no requirement for privacy on reassignments, do not use > them. However there are some reasons that customers need it. > > -dsd > > David Divins > Principal Engineer > ServerVault Corp. > (703) 652-5955 > > > _____ > > From: Internet Partners, Inc. Tech Support [mailto:support at ipinc.net] > Sent: Monday, April 10, 2006 4:39 PM > To: Divins, David; Owen DeLong; ARIN-discuss at arin.net > Subject: RE: [arin-discuss] Privacy of Reassignment Information > > > > Please cite the privacy law you are referring to that prohibits a > company from placing it's name, phone number > and role contact information on an IP assignment. I am unaware of any > such law. > > Just because there's ISP's out there who feel that they can ignore the > rules and fill in bogus contact > information does not mean we should rewrite the system to cater to these > people > > There are always people who regard public trusts as their own personal > property, to abuse as they see > fit, and to ignore the rules the rest of us have setup, because they > feel that somehow they are "special" > that because of who they are and what they do that the rules need to be > adjusted to suit their own > personal agenda. This is called regarding yourself as above the law. > > If we trade in the mandate for ISP's to place valid, public data for > reassignment information into the > database, in exchange for some sort of "NDA trade out" as you are > advocating, then we may make > a small minority happy and make a problem go away, for the time being. > > Then when the next small minority has a beef with the system we are > going to adjust the system > to suit them - because after all we did it for the private numbers > people. And so on and so on. > > Eventually the Internet becomes nothing more than what happened in > Europe in the Middle Ages > with everyone with their own little fiefdom and their own little laws. > > If an ISP or a company does not like the requirement to disclose who > they are, they can simply not > connect to the Internet. Nobody is holding a gun to anyone's head and > telling them they must be > connected to the Internet or else. If they absoluely have to have > e-mail, why last I checked UUCP > worked just fine and did not require a public IP address. > > Ted Mittelstaedt > NOC Manager > Internet Partners, Inc. > > -----Original Message----- > From: arin-discuss-bounces at arin.net > [mailto:arin-discuss-bounces at arin.net]On Behalf Of Divins, David > Sent: Friday, April 07, 2006 10:26 PM > To: Owen DeLong; ARIN-discuss at arin.net > Subject: Re: [arin-discuss] Privacy of Reassignment Information > > > > All IP Allocations are done based upon trust. If an ISP just wanted to > obscure a reassignment they could simply make up a customer. > > Allowing ISP's to enter into NDA type status for reassignments and > representing these reassignments as private in public servers should > provide the registrar with more accurate information-- as that is the > basis for the reassignment policy. Additionally, this provides much > needed privacy for companies that must adhere to ever more restrictive > privacy laws. This allows a valid mechanism. > > Why is a corporate entities right to privacy any less than an > individuals (when it comes to IP space-- and remember not all companies > are public)? > > Why is there a need to know what company owns a block provided there is > a valid contact provided? This probably brings the question of how can > we ensure a valid contact. Since all assignments are done based on > trust, there must be some base assumption that for the most part ISP's > act according to ARIN rules-- I am not aware of any ARIN > para-military-esque auditing arm that checks ISP corporate accounting > against IP assignments to see who skirts the rules. > > Honestly, I would be content to see a policy that allows an ISP to go > full NDA with ARIN and provide reassignment information to ARIN on a > private basis. Under this condition, the ISP would need to maintain > valid contact (abuse/noc) for all address space it has been assigned and > not publicly reassigned. > > I firmly believe that this issue will not be going away. > > -dsd > > David Divins > Principal Engineer > ServerVault Corp. > (703) 652-5955 > > > _____________________________________________ > From: Owen DeLong [ mailto:owen at delong.com] > Sent: Friday, April 07, 2006 11:56 PM > To: Divins, David; ARIN-discuss at arin.net > Subject: Re: [arin-discuss] Privacy of Reassignment Information > > * PGP Signed by an unknown key: 04/07/2006 at 11:55PM > > > > --On April 7, 2006 10:25:11 PM -0400 "Divins, David" > > wrote: > > > All, > > > > Provided an ISP, or other direct assignment recipient, supplies valid > > and responsive (24x7) Abuse, NOC, and other pertinent contact > > information, a reassignment should be allowed to remain private. > > > First, a direct assignment recipient cannot reassign, so, this would > not apply to a direct assignment recipient. > > Second, the policy was abandoned fairly recently due to lack of > support by the community and lack of consensus to move forward. > > IP resources are an element of public trust. It is common and > widespread > practice to disclose as a matter of public record possessory interest > in public resources. The public interest in an open and equitable > system of resource assignments and allocations overrides ISPs > interest in hiding the identities of their customers. > > > > The ability for an ISP to selectively and voluntarily make an > assignment > > private will still allow ARIN to have accurate reassignment > information > > as the assignments will be provided to ARIN privately whenever address > > > utilization must be determined. > > > ARIN is a stewardship organization. The IP addresses are no more owned > by ARIN than by any recipient organization. They are administered by > ARIN and the ISPs in the public trust. They are public resources. > > > The private designation in no way relieves the ISP of its > responsibility > > to the Internet community. In fact, a private reassignment expands > this > > responsibility as the ISP actually must take on the responsibility > > providing valid 24x7 point of contact. > > > The community vehemently opposed adding such a requirement to the > previous > attempt at such a policy. > > > If an ISP is unable or unwilling to provide a responsive NOC/abuse > > contact, then they may not designate any reassignments as private. > > > How would you propose to prevent ISPs from ignoring this requirement? > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. > > > * Unknown Key > * 0x0FE2AA3D - unknown > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From dlw+arin at tellme.com Mon Apr 10 23:32:51 2006 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 10 Apr 2006 20:32:51 -0700 Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: References: <443ABB92.9070504@easydns.com> Message-ID: <20060411033251.GQ13210@shell01.corp.tellme.com> On Mon, Apr 10, 2006 at 05:19:29PM -0400, Scott Leibrand wrote: > Can you elaborate on this? I don't see reachability obstacles, as stated > above. What other obstacles are there to using your existing space to do > anycast? Perhaps we're unique, but I don't think so. We don't announce the same aggregate from any of our sites, so we don't really have a suitable block to choose a /24 out of. In addition, we're a pretty new company (compared to many) so we lack legacy space, and we're generally very efficient in our allocations. We don't really have more than a couple of extra /24s total. (And again, none of them are in a block that is announced from all of our sites.) Fundamentally, we need another block that we can announce from all of our sites. Given the intended usage, why allocate more than necessary? Some of this is pretty darn specific to our site, and while they certainly influenced my decision to try to write a reasonable policy, these aren't the driving factors. I hope this discussion does something to illustrate the need. If I understand your posts, you mostly object to the use of micro-allocation, but agree that there's a need for /24s for anycast. If there's a reasonable justification for actually using microallocations, do you have any other objections? Thanks for the discussion...I appreciate it! -David From woody at pch.net Tue Apr 11 02:17:20 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 10 Apr 2006 23:17:20 -0700 (PDT) Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: References: <443ABB92.9070504@easydns.com> Message-ID: On Mon, 10 Apr 2006, Scott Leibrand wrote: > I have an unanswered question regarding anycast, namely: why do you need a > micro-allocation to do it? You don't. However, if all you need is one IP address, a microallocation is less wasteful than a larger block. > > At present, the minimum allocation requirements pose an obstacle to > > smaller to medium DNS providers who want to test and deploy anycast > > services. > > Can you elaborate on this? I don't see reachability obstacles, as stated > above. What other obstacles are there to using your existing space to do > anycast? Exactly what he said: the minimum allocation requirement. If all you need is one IP address, justifying a /22 requires the making of, um, unsubstantiatable assertions, to ARIN analysts. That's an unfortunate state of affairs, and one which this policy will correct. -Bill From dsd at servervault.com Tue Apr 11 09:13:06 2006 From: dsd at servervault.com (Divins, David) Date: Tue, 11 Apr 2006 09:13:06 -0400 Subject: [ppml] MOVED RE: [arin-discuss] Privacy of Reassignment Information Message-ID: I am not securing systems with obscurity. However, there is no reason to provide an easy directory/mapping of interesting private exchanges to specific subnets. No, they are not necessarily in DNS. -dsd Growing weary but still going -----Original Message----- From: Robert E.Seastrom [mailto:rs at seastrom.com] Sent: Tuesday, April 11, 2006 8:05 AM To: Divins, David Cc: Internet Partners, Inc. Tech Support; ppml at arin.net Subject: Re: [ppml] MOVED RE: [arin-discuss] Privacy of Reassignment Information "Divins, David" writes: > I never said there is a law preventing companies from publishing this data.? > However, the USA does have very strict privacy laws regarding to HIPPA > healthcare information.? If HIPPA healthcare clearing system gets SWIPed it > may provide a vector. I'm not a HIPAA expert, but I'm fairly sure that "security in obscurity" is not a HIPAA-compliant standard of locking things down. ---Rob From sleibrand at internap.com Tue Apr 11 09:26:51 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 11 Apr 2006 09:26:51 -0400 (EDT) Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: References: <443ABB92.9070504@easydns.com> Message-ID: On 04/10/06 at 11:17pm -0700, Bill Woodcock wrote: > On Mon, 10 Apr 2006, Scott Leibrand wrote: > > I have an unanswered question regarding anycast, namely: why do you need a > > micro-allocation to do it? > > You don't. However, if all you need is one IP address, a microallocation > is less wasteful than a larger block. True, but no more less wasteful than using a /24 out of a larger block (if you have one). > > > At present, the minimum allocation requirements pose an obstacle to > > > smaller to medium DNS providers who want to test and deploy anycast > > > services. > > > > Can you elaborate on this? I don't see reachability obstacles, as stated > > above. What other obstacles are there to using your existing space to do > > anycast? > > Exactly what he said: the minimum allocation requirement. If all you need > is one IP address, justifying a /22 requires the making of, um, > unsubstantiatable assertions, to ARIN analysts. That's an unfortunate > state of affairs, and one which this policy will correct. Ok. If this policy is intended for allocations to organizations who don't have PI space, I don't have any real objections to it. I would be somewhat more comfortable if we explicitly stated the expectation that if you have PI space you should use it for this purpose, and only be eligible for a micro-allocation if you're not big enough to need a PI /22. But I won't try to hold up the policy until the next meeting based on that quibble. -Scott From dlw+arin at tellme.com Tue Apr 11 09:34:14 2006 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 11 Apr 2006 06:34:14 -0700 Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: References: <443ABB92.9070504@easydns.com> Message-ID: <20060411133414.GV13210@shell01.corp.tellme.com> On Tue, Apr 11, 2006 at 09:26:51AM -0400, Scott Leibrand wrote: > Ok. If this policy is intended for allocations to organizations who don't > have PI space, I don't have any real objections to it. I would be > somewhat more comfortable if we explicitly stated the expectation that if > you have PI space you should use it for this purpose, and only be eligible > for a micro-allocation if you're not big enough to need a PI /22. But I > won't try to hold up the policy until the next meeting based on that > quibble. I'd like to add that if the PI space you do have is in some way unsuitable, you can still qualify. I'll happily agree that this proposed policy isn't perfect: I don't think we'll know until we get some experience with it. I fully expect that it will get modified in about a year or so. Perhaps we can ad additional requirements or qualifications if the need becomes clear. -David From owen at delong.com Tue Apr 11 10:00:11 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Apr 2006 10:00:11 -0400 Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: References: <443ABB92.9070504@easydns.com> Message-ID: --On April 11, 2006 9:26:51 AM -0400 Scott Leibrand wrote: > On 04/10/06 at 11:17pm -0700, Bill Woodcock wrote: > >> On Mon, 10 Apr 2006, Scott Leibrand wrote: >> > I have an unanswered question regarding anycast, namely: why do >> > you need a micro-allocation to do it? >> >> You don't. However, if all you need is one IP address, a microallocation >> is less wasteful than a larger block. > > True, but no more less wasteful than using a /24 out of a larger block (if > you have one). > However, because at least part of the intent of many anycast implementations is to overcome DDoS, it is at least desirable in many of those cases to be able to put your anycast stuff in a block that is not directly associated with your existing infrastructure. >> > > At present, the minimum allocation requirements pose an obstacle >> > > to smaller to medium DNS providers who want to test and deploy >> > > anycast services. >> > >> > Can you elaborate on this? I don't see reachability obstacles, as >> > stated above. What other obstacles are there to using your >> > existing space to do anycast? >> >> Exactly what he said: the minimum allocation requirement. If all you >> need is one IP address, justifying a /22 requires the making of, um, >> unsubstantiatable assertions, to ARIN analysts. That's an unfortunate >> state of affairs, and one which this policy will correct. > > Ok. If this policy is intended for allocations to organizations who don't > have PI space, I don't have any real objections to it. I would be > somewhat more comfortable if we explicitly stated the expectation that if > you have PI space you should use it for this purpose, and only be eligible > for a micro-allocation if you're not big enough to need a PI /22. But I > won't try to hold up the policy until the next meeting based on that > quibble. > Just out of curiosity, does the information above address your quibble? Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From sleibrand at internap.com Tue Apr 11 10:07:41 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 11 Apr 2006 10:07:41 -0400 (EDT) Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: References: <443ABB92.9070504@easydns.com> Message-ID: On 04/11/06 at 10:00am -0400, Owen DeLong wrote: > However, because at least part of the intent of many anycast implementations > is to overcome DDoS, it is at least desirable in many of those cases to > be able to put your anycast stuff in a block that is not directly associated > with your existing infrastructure. Perhaps. This strikes me as a "security through obscurity" argument, though. > Just out of curiosity, does the information above address your quibble? I'm not sure. I'm having a hard time coming up with any strong opinions on this subject. I think I used them all up on PI. :) -Scott From owen at delong.com Tue Apr 11 11:10:53 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Apr 2006 11:10:53 -0400 Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: References: <443ABB92.9070504@easydns.com> Message-ID: <636556C4718E52555DF4E0C4@host139-198.arin-xvii.arin.net> --On April 11, 2006 10:07:41 AM -0400 Scott Leibrand wrote: > On 04/11/06 at 10:00am -0400, Owen DeLong wrote: > >> However, because at least part of the intent of many anycast >> implementations is to overcome DDoS, it is at least desirable in many of >> those cases to be able to put your anycast stuff in a block that is not >> directly associated with your existing infrastructure. > > Perhaps. This strikes me as a "security through obscurity" argument, > though. > Not exactly. A lot of DDoS stuff scans contiguous address ranges. If your DDoS resistant targets are in a /24 that is part of your larger blocks, then, the scans are not at all unlikely to spill over into your non-resistant unicast services. If your anycast stuff is in a non-contiguous block, this is less likely. The overall impact to the routing table remains the same. >> Just out of curiosity, does the information above address your quibble? > > I'm not sure. I'm having a hard time coming up with any strong opinions > on this subject. I think I used them all up on PI. :) > LOL Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From markjr at easydns.com Tue Apr 11 11:47:39 2006 From: markjr at easydns.com (Mark Jeftovic) Date: Tue, 11 Apr 2006 11:47:39 -0400 Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: <20060411133414.GV13210@shell01.corp.tellme.com> References: <443ABB92.9070504@easydns.com> <20060411133414.GV13210@shell01.corp.tellme.com> Message-ID: <443BCF9B.6050407@easydns.com> Sorry if I don't understand all the lingo (I'm a self-confessed routing moron), what is "PI space"? The issue with just getting a /24 allocated from your ISP or upstream I guess is this ties you to the ISP, if you ever move you then need to get another allocation from your new ISP. Also, what if your anycast cloud straddles across multiple ISPs? Would that still work? that's why I think the micro-allocation is the solution to give the smaller players the flexibility to tie their own anycast clouds together in a manner that doesn't marry them to their upstream -mark David Williamson wrote: > On Tue, Apr 11, 2006 at 09:26:51AM -0400, Scott Leibrand wrote: > >>Ok. If this policy is intended for allocations to organizations who don't >>have PI space, I don't have any real objections to it. I would be >>somewhat more comfortable if we explicitly stated the expectation that if >>you have PI space you should use it for this purpose, and only be eligible >>for a micro-allocation if you're not big enough to need a PI /22. But I >>won't try to hold up the policy until the next meeting based on that >>quibble. > > > I'd like to add that if the PI space you do have is in some way > unsuitable, you can still qualify. I'll happily agree that this > proposed policy isn't perfect: I don't think we'll know until we get > some experience with it. I fully expect that it will get modified in > about a year or so. Perhaps we can ad additional requirements or > qualifications if the need becomes clear. > > -David > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -- Mark Jeftovic Founder & President, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(866) 273-2892 From woody at pch.net Tue Apr 11 11:50:36 2006 From: woody at pch.net (Bill Woodcock) Date: Tue, 11 Apr 2006 08:50:36 -0700 (PDT) Subject: [ppml] 4.4.2 Micro-allocations for anycast services In-Reply-To: <443BCF9B.6050407@easydns.com> References: <443ABB92.9070504@easydns.com> <20060411133414.GV13210@shell01.corp.tellme.com> <443BCF9B.6050407@easydns.com> Message-ID: On Tue, 11 Apr 2006, Mark Jeftovic wrote: > Sorry if I don't understand all the lingo (I'm a self-confessed routing > moron), what is "PI space"? Provider-independent. Space which you get from your RIR rather than from your up-stream. > The issue with just getting a /24 allocated from your ISP or upstream I > guess is this ties you to the ISP, if you ever move you then need to get > another allocation from your new ISP. The upstream may not be happy with you using their space in locations where you're not buying transit from them. > Also, what if your anycast cloud straddles across multiple ISPs? Would > that still work? Not very well. > that's why I think the micro-allocation is the solution to give the > smaller players the flexibility to tie their own anycast clouds together > in a manner that doesn't marry them to their upstream Yup. -Bill From hritter at cisco.com Wed Apr 12 22:56:25 2006 From: hritter at cisco.com (Harold Ritter (hritter)) Date: Wed, 12 Apr 2006 22:56:25 -0400 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure Message-ID: Greetings, Yesterday, I attempted to propose a solution to the problem described in policy proposal 2006-2. I realize that the explanation I gave was somewhat confusing and ipv4 biased, so let me try it again but in ipv6 terms this time. The problem leading to the BGP convergence issue: When the /128 route, used to resolve the BGP next-hop of the current BGP best path, is removed from the RIB because the BGP neighbor has gone down, the BGP next-hop is still resolvable via a less specific route, an aggregate route for instance, which causes the staled BGP paths to remain in the routing table for up to 3 minutes (BGP holdtime) even though one or many other paths are available. This obviously results in traffic being blackholed. The solution: Modify BGP implementations so they only consider host routes (/128) as valid routes to resolve the BGP next-hop. This way, if a router goes down and its loopback interface address disappears from the IGP, its BGP neighbors will immediately be able to react by invalidating all BGP prefixes having this address as their BGP next-hop, which leads to a new BGP best path being selected. This should also be configurable to accept a less specific prefix to cope with cases where /128 prefixes are not injected in the IGP under normal conditions. This solution as been applied and tested with ipv4 and is also applicable to ipv6. The point I would like to get across is that in my view there is ways to handle this issue from a routing protocol standpoint. I hope this clears out the confusion I created when I explained at the conference. Please let me know if you have any questions or comments, BTW: I really enjoyed my first ARIN meeting!! Harold Ritter, CCIE 4168 (R&S / SP) Cisco Advanced Services 1501 McGill College, 6i?me ?tage Montr?al, Qu?bec H3A 3M8 Canada T?l?phone: 514 847-6856 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Thu Apr 13 07:55:00 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 13 Apr 2006 07:55:00 -0400 (EDT) Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure In-Reply-To: References: Message-ID: On 04/12/06 at 10:56pm -0400, Harold Ritter (hritter) wrote: > Modify BGP implementations so they only consider host routes (/128) as > valid routes to resolve the BGP next-hop. This way, if a router goes > down and its loopback interface address disappears from the IGP, its BGP > neighbors will immediately be able to react by invalidating all BGP > prefixes having this address as their BGP next-hop, which leads to a new > BGP best path being selected. This should also be configurable to accept > a less specific prefix to cope with cases where /128 prefixes are not > injected in the IGP under normal conditions. Sounds like a workable solution to me... But... > This solution as been applied and tested with ipv4 and is also > applicable to ipv6. Is this actually available in IOS (for either IPv4 or IPv6)? If not, how long would it take to get it tested and made available? -Scott From plzak at arin.net Thu Apr 13 08:46:05 2006 From: plzak at arin.net (Ray Plzak) Date: Thu, 13 Apr 2006 08:46:05 -0400 Subject: [ppml] [address-policy-wg] RE: Question In-Reply-To: <936A4045C332714F975800409DE09240021C9580@tayexc14.americas.cpqcorp.net> Message-ID: <20060413124609.3F2181FFAA@mercury.arin.net> Jim, Regarding direction, ARIN staff implements policies that have reached community consensus as determined by the ARIN Advisory Council and as ratified by the Board of Trustees. In one sense, ARIN works like the IETF in that it is individuals who contribute to the discussion. An organization is one voice and is not viewed as representative of its members from the standpoint of numbers. You are correct. This does not preclude someone representative of the IPv6 Forum from making a statement on either the ppml or at a meeting on behalf of the Forum. One last point, if the Forum feels that the community is developing policy that is harmful then the Forum should certainly make a statement, more importantly, its individual members should become active voices in the discussion. There are a lot of voices in the IPv6 discussions but the discussion could be much more robust if those of the Forum were included. Ray > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound at hp.com] > Sent: Tuesday, April 11, 2006 9:30 AM > To: Ray Plzak; Latif Ladid ("The New Internet based on IPv6"); Tony Hain; > PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Davis, Terry L; ollivier.robert at eurocontrol.fr; > narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; > Green, David B RDECOM CERDEC STCD SRI; Bound, Jim > Subject: RE: [address-policy-wg] RE: Question > > Ray, So you don't take IETF direction but only from individuals in the > IETF? Just want this to be clarified very clearly. This also does not > preclude the IPv6 Forum stating a public position on the issue whether > RIRs react to it or not. Not that will happen but it could if the pain > is strong enough to prohibit IPv6 deployment. > > Thanks > /jim > > > -----Original Message----- > > From: Ray Plzak [mailto:plzak at arin.net] > > Sent: Monday, April 10, 2006 6:56 AM > > To: 'Latif Ladid ("The New Internet based on IPv6")'; Bound, > > Jim; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, > > Michael P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > > RDECOM CERDEC STCD SRI' > > Subject: RE: [address-policy-wg] RE: Question > > > > The NAv6TF is in the ARIN region. If individuals associated > > with it think that ARIN should adopt a policy or change an > > existing policy they should not only say so they should > > propose such a policy. Remember policies in the ARIN region, > > like in all of the RIRs is made not by the RIR organization > > staff and board but by the community in the region. ARIN > > staff will be more than happy to help anyone through the > > process, which by the way, while an orderly and formal > > process is not onerous, but one designed to provide for an > > open and honest discussion of any policy proposal before it > > is adopted. If you are interested in pursuing this, please > > contact me and I will get a staff member to assist you. > > > > Ray > > > > > -----Original Message----- > > > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > > > admin at ripe.net] On Behalf Of Latif Ladid ("The New Internet based on > > > IPv6") > > > Sent: Saturday, April 08, 2006 9:53 AM > > > To: 'Bound, Jim'; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, Michael P > > > CIV DISA GES-E'; 'Pouffary, Yanick'; 'Green, David B RDECOM > > CERDEC STCD SRI' > > > Subject: [address-policy-wg] RE: Question > > > > > > > > > > > > The technical community should fix this one before the ITU > > sees this > > > as another chance to have a political say on the IPv6 addressing. > > > These things leak fast. My advice is that ARIN should seriously own > > > this issue before the ITU turns it to a sovereignty issue, > > which they > > > could for sure win this time. I know one of their noodles > > is sizzling > > > at it. > > > > > > Cheers > > > Latif > > > > > > -----Original Message----- > > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > > Sent: 08 April 2006 14:52 > > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > > on IPv6"); > > > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > > > Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B > > > RDECOM CERDEC STCD SRI; Bound, Jim > > > Subject: RE: Question > > > > > > Tony, > > > > > > Excellent response and educational for sure. It is my > > belief that the > > > corporate business model today for operating networks may be broken > > > and I think you supported that below? If not my apologies > > for bad parsing? > > > > > > > > > Their models were fine for an IPv4 world where NAT was required and > > > some even confuse NAT with securing ones network (and some > > programs in the U.S. > > > Government) and that is simply bad policy and view. > > > > > > In the interim can this be resolved by RIRs creating some kind of > > > additional wording that address reclaim will be done in > > manner that is > > > negotiable, and do no harm to corporate or government business > > > operations? This would buy us time to work on the issue > > and stop the > > > FUD around this topic? > > > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > > > addressing you can lead as ajunct to one of our regular > > meetings you > > > can lead for an entire day and we get the right players in > > the room. > > > So think about that as another option too. > > > > > > But do enjoy the beach this thread does not have to be > > resolved this > > > week > > > :--) > > > > > > Really want to hear from all of you and discussion Terry D., Latif, > > > Yanick, Dave G. Mike B. etc. > > > > > > Thanks > > > /jim > > > > > > > -----Original Message----- > > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > > Sent: Friday, April 07, 2006 7:57 PM > > > > To: 'PPML'; address-policy-wg at ripe.net > > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > > New Internet > > > > based on IPv6")'; 'Davis, Terry L'; > > ollivier.robert at eurocontrol.fr; > > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > > > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > > > Subject: RE: Question > > > > > > > > A public answer to a private question as I have been sitting on a > > > > beach for awhile without the laptop and missed some related > > > > conversations ... :) > > > > > > > > > Is the outcome really open for discussion on the PI issue? > > > > It doesn't > > > > > sound like it is. > > > > > > > > In the minds of some the route scaling issue outweighs > > any argument > > > > for PI. > > > > When taken to its extreme, there is a valid point that a broken > > > > routing system serves no one. At the same time the > > dogmatic stance > > > > by the ISPs enforcing lock-in is just as broken both for large > > > > organizations with financial or legal requirements for > > operational > > > > stability, and the individual consumer/small business > > with limited > > > > budgets looking for true competition. The hard part is > > finding the > > > > middle ground in a way that limits the exposure to a potential > > > > routing collapse. > > > > > > > > I personally refuse to declare some needs legitimate and > > others not, > > > > as the only point of such differentiation is to establish a power > > > > broker. When all uses are legitimate, the problem boils > > down to the > > > > technical approach that can be scaled as necessary to > > contain growth > > > > in the routing system. > > > > This is the logic that leads me to the bit-interleaved > > geo that can > > > > be aggregated in varying size pockets as necessary using existing > > > > BGP deployments. We can start flat and implement aggregation over > > > > time when a region becomes too large to handle. One nice > > side effect > > > > of this geo approach is that it mitigates the continuing > > political > > > > demands for sovereign rights to IPv6 space. > > > > > > > > Any aggregation approach will force the business models to change > > > > from current practice. That is not as bad a thing as the > > alarmists > > > > will make it out to be, because their accountants are > > claiming the > > > > current model is a broken money looser as it is (which if > > so means > > > > they will eventually change anyway). The primary > > difference is that > > > > there will need to be aggregation intermediaries between the > > > > last-mile and transit providers. The current model > > eliminates these > > > > middle-men by trading off their routing mitigation > > service against a > > > > larger routing table (actually they already exist in the right > > > > places but are currently limited to layer2 media > > aggregators). The > > > > anti-PI bunch is trying to use social engineering to directly > > > > counter the bottom line business reality that the > > customer will always win in the end. > > > > Rather than accept this situation and constructively work on the > > > > necessary business model and technology developments, they > > > > effectively stall progress by staunchly claiming there is no > > > > acceptable technical approach that works within the > > current business structure. > > > > > > > > Making the RIRs be the police deciding who qualifies for > > PI and who > > > > does not just adds to their workload and raises costs. The > > > > beneficiaries of this gatekeeper approach are the ISPs that claim > > > > they need full routing knowledge everywhere, while the > > cost burden > > > > for supporting the waste-of-time qualification/evaluation work is > > > > borne by the applicant. > > > > Given that the most vocal and organized membership in the RIR > > > > community are the ISPs it is easy to understand why it would seem > > > > like the PI issue is already decided as closed. I tend to > > believe it > > > > will just drag out until enough of the corporate world > > becomes aware > > > > of the > > > > IPv4 exhaustion in light of their growth needs that they > > > > collectively appear at their RIR and demand an immediate > > solution. > > > > Unfortunately this 'wait till the last minute' tactic will likely > > > > result in a reactionary quickie with its own set of long > > term side effects. > > > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > > > > told that > > > > shim6 was the anointed solution. Now that at least nanog has told > > > > the IAB where to put shim6 it might be possible to get > > the current > > > > IESG to reconsider. In any case the result would be a technical > > > > approach that would still require RIRs to establish > > policies around. > > > > As long as they are dominated by the ISPs it will be > > difficult to get real PI. > > > > > > > > Tony > > > > > > > > > > > > From dlw+arin at tellme.com Thu Apr 13 11:22:51 2006 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 13 Apr 2006 08:22:51 -0700 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure In-Reply-To: References: Message-ID: <20060413152251.GK13210@shell01.corp.tellme.com> On Thu, Apr 13, 2006 at 07:55:00AM -0400, Scott Leibrand wrote: > On 04/12/06 at 10:56pm -0400, Harold Ritter (hritter) wrote: > > This solution as been applied and tested with ipv4 and is also > > applicable to ipv6. > > Is this actually available in IOS (for either IPv4 or IPv6)? If not, how > long would it take to get it tested and made available? ...and interoperable with other vendors. I do think fixing BGP would be a nice solution...I'm just dubious about the timeline required. It's worth noting that the same problem exists in v4 and v6. It's the general habit of single allocations in v6 that makes it much more noticeable, compared to v4. -David From jason.schiller at mci.com Thu Apr 13 11:27:20 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 13 Apr 2006 11:27:20 -0400 (EDT) Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure In-Reply-To: Message-ID: Scott, The important question is not if this is actually available in IOS, but rather if it is actually available in a version of IOS that service providers are actually willing to run... As for constraining the routes that are used for next-hop resolution, I would suggest that this be as flexible as any other route-map, ACL, or policy. Lastly, *all* router vendors need to support this functionality in order to have a consistant forwarding behavor. Cisco calls this "BGP Selective Next-Hop Route Filtering". http://www.cisco.com/en/US/products/ps6441/products_configuration_guide_chapter09186a00805387d7.html#wp1113697 Configuring BGP Selective Next-Hop Route Filtering: Examples "The following example shows how to configure BGP selective next-hop route filtering to avoid using a BGP prefix as the next-hop route. If the most specific route that covers the next hop is a BGP route, then the BGP route will be marked as unreachable. The next hop must be an IGP or static route. router bgp 45000 address-family ipv4 unicast bgp nexthop route-map CHECK-BGP exit exit route-map CHECK-BGP deny 10 match source-protocol bgp 1 exit route-map CHECK-BGP permit 20 end " This functionality is available ONLY in 12.4T or IOS XR. I have asked for this functionality in 12.0S, and to ensure this functionality is supported in IPv6 as well. I was told it would be highly unlikely to be back ported to 12.0S. Since this is currently a show stopped for me I never followed up if the command works for IPv6 or not. Juniper calls this "resolution ribs" http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-routin g/frameset.htm http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-routing/html/routing-generic-config18.html#1032268 "You can configure a routing table to accept routes from specific routing tables. You can also configure a routing table to use specific import policies to produce a route resolution table to resolve routes." To configure route resolution, include the resolution statement: resolution { rib routing-table-name { import [ policy-names ]; resolution-ribs [ routing-table-names ]; } } " However, until all routing vendors support this functionality it has limited usefulness. Take the case of an all Juniper Core and an all Cisco edge. Destination is reachable through best path to edge-router-1 and non-best path to edge-router-2. Source is connected to edge-router-3. Depending on the topology and the BGP tie breaker, edge-router-2 may or may not announce the non-best path to the core. If the tie breaker is MED for example, then edge-router-2 will no announce a path to the core as the iBGP route from edge-router-1 will be better and will supress the annnouncement. If the tie breaker is say IGP distance, or router ID, then edge-router-2 will announce a path into the core. In the case where edge-router-2 does not announce a path you have black holing for up to 3 mins. (BGP hold time) untill the iBGP neighbor times out. During this time traffic is black holed. In the case where edge-router-2 does announce a path to the core, then the core will have the best and the non-best path to the destination. The edge routers will only have the pull-up or less specific route with a next-hop of the nearest core router. This will cause edge-router-3 to send traffic towards the core. The core will have the new best path and will forward to edge-router-2. Edge-router-2 will still have the old best route with a next-hop of edge-router-1's loopback. Edge-router-1 is reachable through the pull-up (aggregate) route, and traffic will be forwarded to the core. Thus traffic will loop for up to 3 mins (BGP hold time). I was attempting to persue an ARIN policy as wide spread vendor adoption in a code that is useful seems unlikely to have a timely solution. Without this policy, many of my customers who demand fast fail-over for their time sensitive applications (such as VoIP) will continue to believe that IPv6 is just not ready for "prime-time" and will not use IPv6 for production services. Furthermore, 2006-2 was also attempting to address other security concerns that can be resolved by having a second non-contigous aggregate. Router configuration to limit BGP next-hop resolution does not address the security concerns. So the question I have is if it is really worth persuing all of these vendors to get this functionality in a useful code, if the the policy is still going to move forward on only the security needs? I guess my second question is if people are in favor of this policy to solve only the security needs? ___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 Thu, 13 Apr 2006, Scott Leibrand wrote: > Date: Thu, 13 Apr 2006 07:55:00 -0400 (EDT) > From: Scott Leibrand > To: "Harold Ritter (hritter)" > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2006-2: Micro-allocations for > Internal Infrastructure > > On 04/12/06 at 10:56pm -0400, Harold Ritter (hritter) wrote: > > > Modify BGP implementations so they only consider host routes (/128) as > > valid routes to resolve the BGP next-hop. This way, if a router goes > > down and its loopback interface address disappears from the IGP, its BGP > > neighbors will immediately be able to react by invalidating all BGP > > prefixes having this address as their BGP next-hop, which leads to a new > > BGP best path being selected. This should also be configurable to accept > > a less specific prefix to cope with cases where /128 prefixes are not > > injected in the IGP under normal conditions. > > Sounds like a workable solution to me... But... > > > This solution as been applied and tested with ipv4 and is also > > applicable to ipv6. > > Is this actually available in IOS (for either IPv4 or IPv6)? If not, how > long would it take to get it tested and made available? > > -Scott > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From christopher.morrow at gmail.com Thu Apr 13 16:11:48 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 13 Apr 2006 16:11:48 -0400 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure In-Reply-To: References: Message-ID: <75cb24520604131311mc2c10d4x722ccb86e706a14@mail.gmail.com> On 4/12/06, Harold Ritter (hritter) wrote: > > The solution: > > Modify BGP implementations so they only consider host routes (/128) as valid > routes to resolve the BGP next-hop. This way, if a router goes down and its I don't think that's a good plan. you might want, for some reason, to resolve into a network, not a host route, for generalized configuration reasons... Or, rather, I have a specific application today that takes into account that particular feature :) -Chris From jason.schiller at mci.com Thu Apr 13 17:24:35 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 13 Apr 2006 17:24:35 -0400 (EDT) Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure Message-ID: For some reason my post is not showing up on PPML, so I am resending. Sorry if this is a duplicate. ___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. ---------- Forwarded message ---------- Date: Thu, 13 Apr 2006 11:27:20 -0400 (EDT) From: "Jason Schiller (schiller at uu.net)" To: Scott Leibrand Cc: "Harold Ritter (hritter)" , ppml at arin.net Subject: Re: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure Scott, The important question is not if this is actually available in IOS, but rather if it is actually available in a version of IOS that service providers are actually willing to run... As for constraining the routes that are used for next-hop resolution, I would suggest that this be as flexible as any other route-map, ACL, or policy. Lastly, *all* router vendors need to support this functionality in order to have a consistant forwarding behavor. Cisco calls this "BGP Selective Next-Hop Route Filtering". http://www.cisco.com/en/US/products/ps6441/products_configuration_guide_chapter09186a00805387d7.html#wp1113697 Configuring BGP Selective Next-Hop Route Filtering: Examples "The following example shows how to configure BGP selective next-hop route filtering to avoid using a BGP prefix as the next-hop route. If the most specific route that covers the next hop is a BGP route, then the BGP route will be marked as unreachable. The next hop must be an IGP or static route. router bgp 45000 address-family ipv4 unicast bgp nexthop route-map CHECK-BGP exit exit route-map CHECK-BGP deny 10 match source-protocol bgp 1 exit route-map CHECK-BGP permit 20 end " This functionality is available ONLY in 12.4T or IOS XR. I have asked for this functionality in 12.0S, and to ensure this functionality is supported in IPv6 as well. I was told it would be highly unlikely to be back ported to 12.0S. Since this is currently a show stopped for me I never followed up if the command works for IPv6 or not. Juniper calls this "resolution ribs" http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-routin g/frameset.htm http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-routing/html/routing-generic-config18.html#1032268 "You can configure a routing table to accept routes from specific routing tables. You can also configure a routing table to use specific import policies to produce a route resolution table to resolve routes." To configure route resolution, include the resolution statement: resolution { rib routing-table-name { import [ policy-names ]; resolution-ribs [ routing-table-names ]; } } " However, until all routing vendors support this functionality it has limited usefulness. Take the case of an all Juniper Core and an all Cisco edge. Destination is reachable through best path to edge-router-1 and non-best path to edge-router-2. Source is connected to edge-router-3. Depending on the topology and the BGP tie breaker, edge-router-2 may or may not announce the non-best path to the core. If the tie breaker is MED for example, then edge-router-2 will no announce a path to the core as the iBGP route from edge-router-1 will be better and will supress the annnouncement. If the tie breaker is say IGP distance, or router ID, then edge-router-2 will announce a path into the core. In the case where edge-router-2 does not announce a path you have black holing for up to 3 mins. (BGP hold time) untill the iBGP neighbor times out. During this time traffic is black holed. In the case where edge-router-2 does announce a path to the core, then the core will have the best and the non-best path to the destination. The edge routers will only have the pull-up or less specific route with a next-hop of the nearest core router. This will cause edge-router-3 to send traffic towards the core. The core will have the new best path and will forward to edge-router-2. Edge-router-2 will still have the old best route with a next-hop of edge-router-1's loopback. Edge-router-1 is reachable through the pull-up (aggregate) route, and traffic will be forwarded to the core. Thus traffic will loop for up to 3 mins (BGP hold time). I was attempting to persue an ARIN policy as wide spread vendor adoption in a code that is useful seems unlikely to have a timely solution. Without this policy, many of my customers who demand fast fail-over for their time sensitive applications (such as VoIP) will continue to believe that IPv6 is just not ready for "prime-time" and will not use IPv6 for production services. Furthermore, 2006-2 was also attempting to address other security concerns that can be resolved by having a second non-contigous aggregate. Router configuration to limit BGP next-hop resolution does not address the security concerns. So the question I have is if it is really worth persuing all of these vendors to get this functionality in a useful code, if the the policy is still going to move forward on only the security needs? I guess my second question is if people are in favor of this policy to solve only the security needs? ___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 Thu, 13 Apr 2006, Scott Leibrand wrote: > Date: Thu, 13 Apr 2006 07:55:00 -0400 (EDT) > From: Scott Leibrand > To: "Harold Ritter (hritter)" > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2006-2: Micro-allocations for > Internal Infrastructure > > On 04/12/06 at 10:56pm -0400, Harold Ritter (hritter) wrote: > > > Modify BGP implementations so they only consider host routes (/128) as > > valid routes to resolve the BGP next-hop. This way, if a router goes > > down and its loopback interface address disappears from the IGP, its BGP > > neighbors will immediately be able to react by invalidating all BGP > > prefixes having this address as their BGP next-hop, which leads to a new > > BGP best path being selected. This should also be configurable to accept > > a less specific prefix to cope with cases where /128 prefixes are not > > injected in the IGP under normal conditions. > > Sounds like a workable solution to me... But... > > > This solution as been applied and tested with ipv4 and is also > > applicable to ipv6. > > Is this actually available in IOS (for either IPv4 or IPv6)? If not, how > long would it take to get it tested and made available? > > -Scott > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From jordi.palet at consulintel.es Fri Apr 14 06:20:06 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 14 Apr 2006 12:20:06 +0200 Subject: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: <936A4045C332714F975800409DE0924002217015@tayexc14.americas.cpqcorp.net> Message-ID: Hi Jim, Not sure if I got your question correctly, but let me try to explain my view. I understand the position of the people that say they need PI today, especially because not having it may be hurting the advancement of the IPv6 deployment. However, I want to balance this with the medium-long term implications created in the routing table and with the time needed to build and deploy a better technical solution (or several) which is accepted by the community. So my proposal basically is about having PI now everywhere (once ARIN adopt it, is unfair not having it in other regions), but those PI allocations for multihoming should be temporary and those address blocks returned to the RIRs some time (lets say 3 years) after the new technical solution is declared as a valid one. At this way, on the long-run, we will not have routing table implications, but we allow now the people that want to move ahead only if they have a multihoming solution doing so. This 3-years time for getting a multihoming network back to the new technical solution (once adopted) is enough time, I think (it could be changed to 5 years if needed, or whatever), so nobody today see the temporarily of the proposal as a showstopper to go for it now. Regards, Jordi > De: "Bound, Jim" > Responder a: > Fecha: Fri, 14 Apr 2006 03:11:58 -0400 > Para: , > Conversaci?n: PI addressing in IPv6 advances in ARIN > Asunto: RE: PI addressing in IPv6 advances in ARIN > > Jordi, why this will work as is for now? > /jim > >> -----Original Message----- >> From: owner-v6ops at ops.ietf.org >> [mailto:owner-v6ops at ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ >> Sent: Thursday, April 13, 2006 5:28 PM >> To: v6ops at ops.ietf.org >> Subject: Re: PI addressing in IPv6 advances in ARIN >> >> Hi Thomas, all, >> >> During my fly-back from Montreal, I've worked in a proposal >> and I'm talking to folks in each RIR/region, with the idea to >> submit it to all them as a kind of (if possible), global policy. >> >> The idea is based on the comments that I did at the mic >> during the ARIN meeting. >> >> I will try to get this submitted next Monday/Tuesday and get >> ready for a formal presentation during the next RIPE meeting >> at Istanbul (following week). >> >> Regards, >> Jordi >> >> >> >> >>> De: Thomas Narten >>> Responder a: >>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400 >>> Para: "Gunter Van de Velde (gvandeve)" >>> CC: "v6ops at ops.ietf.org" >>> Asunto: Re: PI addressing in IPv6 advances in ARIN >>> >>>> What would be the prefix allocation per organization? >>> >>> /48, though can be larger in some cases. Watch for the revised >>> proposal that gets last called for details. >>> >>>> (Me being in Europe and not attending ARIN sessions) >>> >>> Note: none of the other RIRs have such a policy in place >> today, though >>> I wouldn't be surprised if they now followup with proposals >> of their >>> own (though someone has to do it). >>> >>>> Has there been study on the # of organizations going for >> this and if >>>> the impact will be more significant then more's law on technology >>>> enhancement? >>> >>> Mostly just hand waving, with a lot of "IPv4 hasn't melted today," >>> "looking at the impact of the current IPv4 policies, the >> number of PI >>> assignments is only on the 100s per year", and "we can update the >>> policy if things get problematical". >>> >>> Thomas >>> >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be >> for the use of the individual(s) named above. If you are not >> the intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, >> including attached files, is prohibited. >> >> >> >> >> > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owen at delong.com Fri Apr 14 06:48:34 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Apr 2006 03:48:34 -0700 Subject: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: References: Message-ID: <45724B568004AB728EEE8258@imac-en0.delong.sj.ca.us> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ wrote: [snip] > However, I want to balance this with the medium-long term implications > created in the routing table and with the time needed to build and deploy > a better technical solution (or several) which is accepted by the > community. > I think we first need to define what we consider a solution... See below. > So my proposal basically is about having PI now everywhere (once ARIN > adopt it, is unfair not having it in other regions), but those PI > allocations for multihoming should be temporary and those address blocks > returned to the RIRs some time (lets say 3 years) after the new technical > solution is declared as a valid one. > I would not actually support this idea. The whole point of having PI space is to have the addresses for a long-term. Having a timeframe for return would simply restore the same barrier to entry that existed prior to passing the policy. Other RIRs are free to implement whatever v6 PI policy they feel is appropriate for their region. I would support a globally standardized v6 PI policy along the lines of ARIN 2005-1. However, I would like to argue that if the new technical solution will benefit from the return of this address space, it is most likely not truly a solution, but, instead, another clever hack piled on top of the existing set of hacks. I suppose if someone found the magic bullet to make geotopological addressing really work, that might qualify. However, I have very low expectations in that area. Absent that, any true solution will involve making the size of the routing table independent of the number of PI (or even PA) blocks issued by the RIRs or will make the size of the routing table practically irrelevant. I know this isn't the easy solution, but, we need to look long and hard at the way we do things. I think that solving these problems is going to require a significant paradigm shift. Assuming that we can use IP addresses for both end system identification and for routing topology indicators is how we created this problem. I don't see solving it without breaking that assumption, at least at the interdomain level. > At this way, on the long-run, we will not have routing table implications, > but we allow now the people that want to move ahead only if they have a > multihoming solution doing so. > If you think there is a possible solution (a real solution, not just a hack that postpones the inevitable at the expense of usability like CIDR did), then I'd like to hear what you are thinking. > This 3-years time for getting a multihoming network back to the new > technical solution (once adopted) is enough time, I think (it could be > changed to 5 years if needed, or whatever), so nobody today see the > temporarily of the proposal as a showstopper to go for it now. > I think you underestimate the momentum and requirements of the modern enterprise if you believe that to be true. Any capability available in v4 that is not available on at least equal or better terms in v6 is a deterrent to v6 deployment. The ability to get permanent addresses which do not have to be returned when you switch providers or renumbered on a schedule determined by some external organization is a major example of such a capability. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jordi.palet at consulintel.es Fri Apr 14 07:24:31 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 14 Apr 2006 13:24:31 +0200 Subject: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: <4.3.2.7.2.20060414123720.0369ed10@strange-brew> Message-ID: See below. Regards, Jordi > De: "Gunter Van de Velde (gvandeve)" > Responder a: > Fecha: Fri, 14 Apr 2006 12:43:31 +0200 > Para: > CC: "v6ops at ops.ietf.org" , "ppml at arin.net" > , "shim6 at psg.com" > Asunto: Re: PI addressing in IPv6 advances in ARIN > > Hi Jordi, > > Please see inline. > > At 12:20 14/04/2006 +0200, JORDI PALET MARTINEZ wrote: >> Hi Jim, >> >> Not sure if I got your question correctly, but let me try to explain my >> view. >> >> I understand the position of the people that say they need PI today, >> especially because not having it may be hurting the advancement of the IPv6 >> deployment. >> >> However, I want to balance this with the medium-long term implications >> created in the routing table and with the time needed to build and deploy a >> better technical solution (or several) which is accepted by the community. >> >> So my proposal basically is about having PI now everywhere (once ARIN adopt >> it, is unfair not having it in other regions), but those PI allocations for >> multihoming should be temporary and those address blocks returned to the >> RIRs some time (lets say 3 years) after the new technical solution is >> declared as a valid one. > > That will never happen i suppose... once there is PI space out there, then > it will be there forever.... the discussion in 2 a 3 years will be the same > as now because > Network Management staff just don't like to renumber their infrastructures > (and that is > for valid reasons), and this is even more valid when speaking about the very > large enterprise organizations. If PI is accepted now, then i suppose it > will be out there > forever and ever. Precisely, writing it in the policy will make clear what is not forever. Even if the policy don't say it is temporary, it can be changed at any time. I think is more fair to tell it clearly since the time time the policy is accepted. By the way, something else that I've in my proposal is clarifying that if a use of this policy don't want to go to the technical solution later on, he has, of course, the chance to become an LIR at that time and avoid renumbering (of course, needs to qualify for LIR). > > When PI space is out there then i wonder who of these organizations would > actually > still be interested in a shim solution and further development may result > in an academical > effort. I'm not necessarily talking about shim or only about shim. I hope there will be solutions that will make attractive going for this change. > > Brgds, > G/ > >> At this way, on the long-run, we will not have routing table implications, >> but we allow now the people that want to move ahead only if they have a >> multihoming solution doing so. >> >> This 3-years time for getting a multihoming network back to the new >> technical solution (once adopted) is enough time, I think (it could be >> changed to 5 years if needed, or whatever), so nobody today see the >> temporarily of the proposal as a showstopper to go for it now. >> >> Regards, >> Jordi >> >> >> >> >>> De: "Bound, Jim" >>> Responder a: >>> Fecha: Fri, 14 Apr 2006 03:11:58 -0400 >>> Para: , >>> Conversaci?n: PI addressing in IPv6 advances in ARIN >>> Asunto: RE: PI addressing in IPv6 advances in ARIN >>> >>> Jordi, why this will work as is for now? >>> /jim >>> >>>> -----Original Message----- >>>> From: owner-v6ops at ops.ietf.org >>>> [mailto:owner-v6ops at ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ >>>> Sent: Thursday, April 13, 2006 5:28 PM >>>> To: v6ops at ops.ietf.org >>>> Subject: Re: PI addressing in IPv6 advances in ARIN >>>> >>>> Hi Thomas, all, >>>> >>>> During my fly-back from Montreal, I've worked in a proposal >>>> and I'm talking to folks in each RIR/region, with the idea to >>>> submit it to all them as a kind of (if possible), global policy. >>>> >>>> The idea is based on the comments that I did at the mic >>>> during the ARIN meeting. >>>> >>>> I will try to get this submitted next Monday/Tuesday and get >>>> ready for a formal presentation during the next RIPE meeting >>>> at Istanbul (following week). >>>> >>>> Regards, >>>> Jordi >>>> >>>> >>>> >>>> >>>>> De: Thomas Narten >>>>> Responder a: >>>>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400 >>>>> Para: "Gunter Van de Velde (gvandeve)" >>>>> CC: "v6ops at ops.ietf.org" >>>>> Asunto: Re: PI addressing in IPv6 advances in ARIN >>>>> >>>>>> What would be the prefix allocation per organization? >>>>> >>>>> /48, though can be larger in some cases. Watch for the revised >>>>> proposal that gets last called for details. >>>>> >>>>>> (Me being in Europe and not attending ARIN sessions) >>>>> >>>>> Note: none of the other RIRs have such a policy in place >>>> today, though >>>>> I wouldn't be surprised if they now followup with proposals >>>> of their >>>>> own (though someone has to do it). >>>>> >>>>>> Has there been study on the # of organizations going for >>>> this and if >>>>>> the impact will be more significant then more's law on technology >>>>>> enhancement? >>>>> >>>>> Mostly just hand waving, with a lot of "IPv4 hasn't melted today," >>>>> "looking at the impact of the current IPv4 policies, the >>>> number of PI >>>>> assignments is only on the 100s per year", and "we can update the >>>>> policy if things get problematical". >>>>> >>>>> Thomas >>>>> >>>> >>>> >>>> >>>> >>>> ********************************************** >>>> The IPv6 Portal: http://www.ipv6tf.org >>>> >>>> Barcelona 2005 Global IPv6 Summit >>>> Slides available at: >>>> http://www.ipv6-es.com >>>> >>>> This electronic message contains information which may be >>>> privileged or confidential. The information is intended to be >>>> for the use of the individual(s) named above. If you are not >>>> the intended recipient be aware that any disclosure, copying, >>>> distribution or use of the contents of this information, >>>> including attached files, is prohibited. >>>> >>>> >>>> >>>> >>>> >>> >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri Apr 14 07:39:07 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 14 Apr 2006 13:39:07 +0200 Subject: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: <45724B568004AB728EEE8258@imac-en0.delong.sj.ca.us> Message-ID: Hi Owen, You said it: If somebody find the good solution, it will be attractive to the people to go for it. Otherwise, you always have the chance to become an LIR. My proposal actually is already considering this point and a way to avoid a need for renumbering if that happens. I just want to make sure that we have a way-out if it becomes necessary, but avoid a showstopper now. I think is it possible. I don't have a technical solution yet (and agree with your views on this in the email below in general), but I'm confident we will have. If it will take 4 years from now, or just 2, who knows, so my proposal is ensuring that we have those 4 years+3 for allowing the people either to return the block, or become an LIR and avoid renumbering an any changes in their network. By the way, it may happen, and I'm hoping so, that the technical solution don't make necessary to return the PI block anymore, and in that case, we will be even able to remove at that time the "temporarily" point in the policy (if it becomes accepted). Regards, Jordi > De: Owen DeLong > Responder a: > Fecha: Fri, 14 Apr 2006 03:48:34 -0700 > Para: , "v6ops at ops.ietf.org" , > "ppml at arin.net" , "shim6 at psg.com" > Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN > > > > --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ > wrote: > > [snip] >> However, I want to balance this with the medium-long term implications >> created in the routing table and with the time needed to build and deploy >> a better technical solution (or several) which is accepted by the >> community. >> > I think we first need to define what we consider a solution... See below. > >> So my proposal basically is about having PI now everywhere (once ARIN >> adopt it, is unfair not having it in other regions), but those PI >> allocations for multihoming should be temporary and those address blocks >> returned to the RIRs some time (lets say 3 years) after the new technical >> solution is declared as a valid one. >> > I would not actually support this idea. The whole point of having PI > space is to have the addresses for a long-term. Having a timeframe for > return would simply restore the same barrier to entry that existed > prior to passing the policy. > > Other RIRs are free to implement whatever v6 PI policy they feel is > appropriate for their region. I would support a globally standardized > v6 PI policy along the lines of ARIN 2005-1. > > However, I would like to argue that if the new technical solution will > benefit from the return of this address space, it is most likely not > truly a solution, but, instead, another clever hack piled on top of > the existing set of hacks. > > I suppose if someone found the magic bullet to make geotopological > addressing really work, that might qualify. However, I have very low > expectations in that area. > > Absent that, any true solution will involve making the size of the routing > table independent of the number of PI (or even PA) blocks issued by > the RIRs or will make the size of the routing table practically > irrelevant. > > I know this isn't the easy solution, but, we need to look long and > hard at the way we do things. I think that solving these problems > is going to require a significant paradigm shift. Assuming that we > can use IP addresses for both end system identification and for > routing topology indicators is how we created this problem. I don't > see solving it without breaking that assumption, at least at the > interdomain level. > > >> At this way, on the long-run, we will not have routing table implications, >> but we allow now the people that want to move ahead only if they have a >> multihoming solution doing so. >> > If you think there is a possible solution (a real solution, not just > a hack that postpones the inevitable at the expense of usability > like CIDR did), then I'd like to hear what you are thinking. > >> This 3-years time for getting a multihoming network back to the new >> technical solution (once adopted) is enough time, I think (it could be >> changed to 5 years if needed, or whatever), so nobody today see the >> temporarily of the proposal as a showstopper to go for it now. >> > I think you underestimate the momentum and requirements of the modern > enterprise if you believe that to be true. Any capability available > in v4 that is not available on at least equal or better terms in v6 > is a deterrent to v6 deployment. > > The ability to get permanent addresses which do not have to be returned > when you switch providers or renumbered on a schedule determined by > some external organization is a major example of such a capability. > > Owen > > > -- > If it wasn't crypto-signed, it probably didn't come from me. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri Apr 14 08:14:38 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 14 Apr 2006 14:14:38 +0200 Subject: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: Message-ID: Hi all, My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE and the rest of the regions, trying to get a consensus for a "global" policy on this, but as this thread is being followed up in several mail exploders, to avoid a long cross-posting, I think it will be better to start some discussion already in a mailing list which is global, and actually I think we have the right one ... global-v6 at lists.apnic.net So, if you aren't subscribed in the global-v6 at lists.apnic.net, and you're interested in this thread, please subscribe at http://mailman.apnic.net/mailman/listinfo/global-v6 If you're late because the Eastern, the archives are also available at http://www.apnic.net/mailing-lists/global-v6/ Regards, Jordi > De: JORDI PALET MARTINEZ > Responder a: > Fecha: Fri, 14 Apr 2006 13:39:07 +0200 > Para: "v6ops at ops.ietf.org" , "ppml at arin.net" > , "shim6 at psg.com" > Conversaci?n: [ppml] PI addressing in IPv6 advances in ARIN > Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN > > Hi Owen, > > You said it: If somebody find the good solution, it will be attractive to > the people to go for it. Otherwise, you always have the chance to become an > LIR. My proposal actually is already considering this point and a way to > avoid a need for renumbering if that happens. > > I just want to make sure that we have a way-out if it becomes necessary, but > avoid a showstopper now. I think is it possible. > > I don't have a technical solution yet (and agree with your views on this in > the email below in general), but I'm confident we will have. If it will take > 4 years from now, or just 2, who knows, so my proposal is ensuring that we > have those 4 years+3 for allowing the people either to return the block, or > become an LIR and avoid renumbering an any changes in their network. > > By the way, it may happen, and I'm hoping so, that the technical solution > don't make necessary to return the PI block anymore, and in that case, we > will be even able to remove at that time the "temporarily" point in the > policy (if it becomes accepted). > > Regards, > Jordi > > > > >> De: Owen DeLong >> Responder a: >> Fecha: Fri, 14 Apr 2006 03:48:34 -0700 >> Para: , "v6ops at ops.ietf.org" >> , >> "ppml at arin.net" , "shim6 at psg.com" >> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >> >> >> >> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ >> wrote: >> >> [snip] >>> However, I want to balance this with the medium-long term implications >>> created in the routing table and with the time needed to build and deploy >>> a better technical solution (or several) which is accepted by the >>> community. >>> >> I think we first need to define what we consider a solution... See below. >> >>> So my proposal basically is about having PI now everywhere (once ARIN >>> adopt it, is unfair not having it in other regions), but those PI >>> allocations for multihoming should be temporary and those address blocks >>> returned to the RIRs some time (lets say 3 years) after the new technical >>> solution is declared as a valid one. >>> >> I would not actually support this idea. The whole point of having PI >> space is to have the addresses for a long-term. Having a timeframe for >> return would simply restore the same barrier to entry that existed >> prior to passing the policy. >> >> Other RIRs are free to implement whatever v6 PI policy they feel is >> appropriate for their region. I would support a globally standardized >> v6 PI policy along the lines of ARIN 2005-1. >> >> However, I would like to argue that if the new technical solution will >> benefit from the return of this address space, it is most likely not >> truly a solution, but, instead, another clever hack piled on top of >> the existing set of hacks. >> >> I suppose if someone found the magic bullet to make geotopological >> addressing really work, that might qualify. However, I have very low >> expectations in that area. >> >> Absent that, any true solution will involve making the size of the routing >> table independent of the number of PI (or even PA) blocks issued by >> the RIRs or will make the size of the routing table practically >> irrelevant. >> >> I know this isn't the easy solution, but, we need to look long and >> hard at the way we do things. I think that solving these problems >> is going to require a significant paradigm shift. Assuming that we >> can use IP addresses for both end system identification and for >> routing topology indicators is how we created this problem. I don't >> see solving it without breaking that assumption, at least at the >> interdomain level. >> >> >>> At this way, on the long-run, we will not have routing table implications, >>> but we allow now the people that want to move ahead only if they have a >>> multihoming solution doing so. >>> >> If you think there is a possible solution (a real solution, not just >> a hack that postpones the inevitable at the expense of usability >> like CIDR did), then I'd like to hear what you are thinking. >> >>> This 3-years time for getting a multihoming network back to the new >>> technical solution (once adopted) is enough time, I think (it could be >>> changed to 5 years if needed, or whatever), so nobody today see the >>> temporarily of the proposal as a showstopper to go for it now. >>> >> I think you underestimate the momentum and requirements of the modern >> enterprise if you believe that to be true. Any capability available >> in v4 that is not available on at least equal or better terms in v6 >> is a deterrent to v6 deployment. >> >> The ability to get permanent addresses which do not have to be returned >> when you switch providers or renumbered on a schedule determined by >> some external organization is a major example of such a capability. >> >> Owen >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From chuegen at cisco.com Fri Apr 14 09:21:03 2006 From: chuegen at cisco.com (Craig Huegen (chuegen)) Date: Fri, 14 Apr 2006 09:21:03 -0400 Subject: [ppml] PI addressing in IPv6 advances in ARIN Message-ID: On Friday, April 14, 2006 6:54 AM, Alain Durand wrote: > A) if PI addresses are to be returned at some point in time, > they loose a dreat deal of their value. Folks like PI because > it shields them from renumbering. I'd like to clarify this a bit. As a large enterprise network operator, I'm less concerned about the need to renumber the network once than I am the need to renumber every time that I want to change a service provider. Don't take that the wrong way: renumbering is still a significant pain, but the real reason that enterprises haven't adopted PA space is that it represents a de-facto "lock-in" to the service providers they choose initially and they're faced with a network-wide renumber any time they drop or add a service provider. Most enterprise network operators that I have spoken to would be willing to renumber once in the future, in exchange for a reasonable way to get portable IPv6 space today. > B) any address reclaim process might be lenghty and costly Maybe I'm being overly simplistic, but the policy can set a recovery timeframe in its allocation of PI space to end users and the market forces can drive the recovery based on the impact to the infrastructure. If only a few hundred prefixes are handed out, it might not be enough of a problem to force recovery. This may be a moot point for the ARIN discussion, though, as ARIN typically doesn't play all that much of an enforcer role. It can declare prefixes and prefix ranges as dead, but reachability is determined by the service providers. > C) given how long the shim6/multi homing has taken so far, it > seems hazardous to make any bet that in 3 years it will be > finish, implemented, adopted, deployed... I think that Jordi was referring to 3 years after the solution is declared "available" -- admittedly that's a tough milestone to set. Finally, I agree with all four other points you make; adoption of IPv6 has been held up because the capabilities offered lack a critical requirement for enterprise networks (connectivity without de-facto service provider lock-in). The agreement to move forward with a policy is a very positive thing that enables IPv6 to work for large enterprises while the right solution is determined and rolled out. /cah --- Craig A. Huegen, IT Solutions Architect C i s c o S y s t e m s IT - Intelligent Network Solutions || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen at cisco.com CCIE #2100 ..:||||||:..:||||||:.. From chuegen at cisco.com Fri Apr 14 10:36:32 2006 From: chuegen at cisco.com (Craig Huegen (chuegen)) Date: Fri, 14 Apr 2006 10:36:32 -0400 Subject: [ppml] PI addressing in IPv6 advances in ARIN Message-ID: On Friday, April 14, 2006 9:02 AM, Durand, Alain wrote: >> -----Original Message----- >> From: Craig Huegen (chuegen) [mailto:chuegen at cisco.com] >>> B) any address reclaim process might be lenghty and costly >> >> Maybe I'm being overly simplistic, but the policy can set a >> recovery timeframe in its allocation of PI space to end users >> and the market forces can drive the recovery based on the impact to >> the infrastructure. If only a few hundred prefixes are handed out, >> it might not be enough of a problem to force recovery. > > One could argue that if we are only talking about a few hundred > prefixes, Why do we care reclaiming them? I agree with that argument, _if_ there are only a few hundred. I'm also leaving room for a case here that results in tens of thousands of these prefixes being routed (for instance, if the community can't reach any consensus on architectures for many years). I believe that the RIR's who assign PI space should do so with explicit agreement that there may need to be a reclamation in the future, when a new architecture exists. RIR's do not have the ability to enforce that today except through some specific policy hurdles and perhaps some fee structuring. The primary enforcer will likely need to be service providers, depending upon the pain they feel from having to carry these prefixes. /cah --- Craig A. Huegen, IT Solutions Architect C i s c o S y s t e m s IT - Intelligent Network Solutions || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen at cisco.com CCIE #2100 ..:||||||:..:||||||:.. From sleibrand at internap.com Fri Apr 14 11:14:51 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 14 Apr 2006 11:14:51 -0400 (EDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Message-ID: On 04/14/06 at 5:07pm +0200, Iljitsch van Beijnum wrote: > On 14-apr-2006, at 16:57, Scott Leibrand wrote: > > > 60 voted in favor of moving forward with PI. 6 voted against. > > Wow, 10 to 1. Amazing. > > Even more amazing: 60 people who represent nobody but their own > paycheck get to blow up the internet. Did you participate in the process? Even if you can't justify travel to Montreal, the PPML is wide open. ARIN doesn't go solely by the vote in the room; they also consider whether there was consensus on the PPML. > Where is ICANN when you need it? This little experiment in playground > democracy has to end before people get hurt. I think the ARIN process is closer to the IETF's "rough consensus" process than to "democracy". If you think the PI policy ARIN passed will "blow up the internet", I would encourage you to participate in drafting policy proposals to help limit the impact of PI on the routing table. Bear in mind that we didn't approve an "IPv6 PI for everyone" policy precisely to avoid "blowing up the Internet": instead we only extended existing IPv4 policy to IPv6. As I've written before, I'm attempting to draft an ARIN policy proposal to ensure PI addresses are assigned in a regular fashion instead of the random chronological fashion we do now with IPv4. As you seem to support that, I would encourage you to help draft such a policy proposal and help get people to support it. -Scott P.S. I don't think we need quite so much cross-posting as this... From tme at multicasttech.com Fri Apr 14 11:21:34 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 14 Apr 2006 11:21:34 -0400 Subject: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: <173E8519-DCA6-4D2A-ADFA-1542F24605CB@muada.com> References: <936A4045C332714F975800409DE0924002217015@tayexc14.americas.cpqcorp.net> <4.3.2.7.2.20060414123720.0369ed10@strange-brew> <173E8519-DCA6-4D2A-ADFA-1542F24605CB@muada.com> Message-ID: On Apr 14, 2006, at 7:14 AM, Iljitsch van Beijnum wrote: > While I'm in a nasty mood anyway, let me make the most of it... > > Would you people prune the god damn quotes already!!!!!! It might be a good idea to stop cross posting to 3 lists while you are at it. Regards Marshall (who will send future replies to ppml only) From Ed.Lewis at neustar.biz Fri Apr 14 11:45:13 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 14 Apr 2006 11:45:13 -0400 Subject: [ppml] in room "votes"...was Re: PI addressing in IPv6 advances In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Message-ID: (Regular PPML participants can skip this, it's just an affirmation of what the "votes" mean to the process.) At 11:14 -0400 4/14/06, Scott Leibrand wrote: >On 04/14/06 at 5:07pm +0200, Iljitsch van Beijnum wrote: > >> On 14-apr-2006, at 16:57, Scott Leibrand wrote: >> >> > 60 voted in favor of moving forward with PI. 6 voted against. >> >> Wow, 10 to 1. Amazing. >> >> Even more amazing: 60 people who represent nobody but their own >> paycheck get to blow up the internet. > >Did you participate in the process? Even if you can't justify travel to >Montreal, the PPML is wide open. > >ARIN doesn't go solely by the vote in the room; they also consider whether >there was consensus on the PPML. I can't find the previous messages in this thread, so I don't know who to attribute the comments about the "voting" too. The "vote" at the meeting is "input to the ARIN Advisory Council." The ARIN AC formulates the policy proposal from that (as elected representatives, providing expert review). The proposed policy isn't enacted until the Board of Trustees (also [mostly] elected) approves it. IOW - the 60-6 vote doesn't mean ARIN has approved PI addressing. It's a measure of that the in-room attendees feel ought to be done. PPML expressed opinions also count. PPML in particular. See: http://www.arin.net/policy/irpep.html, quoting: Advisory Council Review Following discussion at the ARIN Public Policy Meeting, the Advisory Council will evaluate the proposal for community support based on comments from the Public Policy Mailing List as well as discussion and polling from the meetings....Comments on the Public Policy Mailing List are given as much weight as those made at the Public Policy Meeting, as it is recognized the mailing list provides access to the process that does not require physical presence at a meeting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From randy at psg.com Fri Apr 14 14:48:03 2006 From: randy at psg.com (Randy Bush) Date: Fri, 14 Apr 2006 08:48:03 -1000 Subject: [ppml] PI addressing in IPv6 advances in ARIN References: <936A4045C332714F975800409DE0924002217015@tayexc14.americas.cpqcorp.net> Message-ID: <17471.61027.305383.689473@roam.psg.com> > So my proposal basically is about having PI now everywhere (once ARIN adopt > it, is unfair not having it in other regions), but those PI allocations for > multihoming should be temporary and those address blocks returned to the > RIRs some time (lets say 3 years) after the new technical solution is > declared as a valid one. and why will the result be different than the japanese experiment, where *temporary* PI v4 space was given out to encourage v6 use, and has never been returned to the pool? what i am hearing are well-meaning but non-op v6 marketeers heavily pushing lots'o v6 pi space, a few ops (e.g. terry) pushing "if folk can't get pi space they won't join the internet," and the rest of us trying to see through the smoke to find a win-win in that works operationally for both the users and the routers. we all think folk should get what they need. we just have differing perceptions of need and of mechanisms to test those needs. randy From owen at delong.com Fri Apr 14 14:54:20 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Apr 2006 11:54:20 -0700 Subject: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: References: Message-ID: <230986FA51D4397BB247CFCD@imac-en0.delong.sj.ca.us> --On April 14, 2006 1:39:07 PM +0200 JORDI PALET MARTINEZ wrote: > Hi Owen, > > You said it: If somebody find the good solution, it will be attractive to > the people to go for it. Otherwise, you always have the chance to become > an LIR. My proposal actually is already considering this point and a way > to avoid a need for renumbering if that happens. > The problem with the LIR qualification idea is that there is a requirement for a plan to assign to 200 external organizations. There are two problems with this requirement. First, there is no clear definition of the term external in this context. Second, the number 200 is rather arbitrary. A /32 is 65,536 possible customer assignments. The number 200 is not related to this fact in any meaningful way. It could just as easily be justified at 100, 10, 2000, 20000, 30000 or whatever. I am not a big fan of arbitrary policy and that seems pretty arbitrary to me. I'm also not a big fan of putting the RIRs in the role of creating more than one class of internet citizenship and providing advantages to organizations that meet certain criteria. I don't know if you were involved back when CIDR first came into being or not. At the time, nobody viewed it as a solution. We all viewed it as a temporary hack until a better solution was devised in v6. It was supposed to all get fixed in v6. That was one of the primary reasons for abandoning TUBA early on. > I just want to make sure that we have a way-out if it becomes necessary, > but avoid a showstopper now. I think is it possible. > My point is that if it becomes necessary, it will be because we have not found a true solution. > I don't have a technical solution yet (and agree with your views on this > in the email below in general), but I'm confident we will have. If it > will take 4 years from now, or just 2, who knows, so my proposal is > ensuring that we have those 4 years+3 for allowing the people either to > return the block, or become an LIR and avoid renumbering an any changes > in their network. > I understand your proposal. Frankly, if I didn't think an expiry clause would be a showstopper, I wouldn't hesitate to agree with it. However, since I believe: 1. It would be a showstopper for a lot of enterprises. 2. The necessity of reclaiming the addresses is symptomatic of an inadequate "solution" > By the way, it may happen, and I'm hoping so, that the technical solution > don't make necessary to return the PI block anymore, and in that case, we > will be even able to remove at that time the "temporarily" point in the > policy (if it becomes accepted). > Right. I am hard pressed to envision any solution that does not have that property. This is why I said I think we need to clearly define what constitutes a solution. In my opinion, to be a solution, rather than a hack, it must have the following properties: 1. Routing table growth is either unconstrained or unrelated to prefix deaggregation. 2. The existence of a reachable connected prefix in one part of the network does not automatically create resource cost in all other default-free parts of the network. 3. Topological convenience from the ISP perspective is not an overriding concern in address policy. 4. Interdomain Routing topology should not need to be a concern in the eligibility to obtain a direct assignment or allocation. 5. The size of the organization should affect only the amount of address space they can receive. It should not control their ability to receive portable address space. If you define a solution along the lines of those 5 points, then, when we have a solution, there is no need to eliminate these assignments. If, on the other hand, we declare victory short of these goals, then, I believe we have again missed the mark and need to keep working. Owen > Regards, > Jordi > > > > >> De: Owen DeLong >> Responder a: >> Fecha: Fri, 14 Apr 2006 03:48:34 -0700 >> Para: , "v6ops at ops.ietf.org" >> , "ppml at arin.net" , "shim6 at psg.com" >> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >> >> >> >> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ >> wrote: >> >> [snip] >>> However, I want to balance this with the medium-long term implications >>> created in the routing table and with the time needed to build and >>> deploy a better technical solution (or several) which is accepted by the >>> community. >>> >> I think we first need to define what we consider a solution... See below. >> >>> So my proposal basically is about having PI now everywhere (once ARIN >>> adopt it, is unfair not having it in other regions), but those PI >>> allocations for multihoming should be temporary and those address blocks >>> returned to the RIRs some time (lets say 3 years) after the new >>> technical solution is declared as a valid one. >>> >> I would not actually support this idea. The whole point of having PI >> space is to have the addresses for a long-term. Having a timeframe for >> return would simply restore the same barrier to entry that existed >> prior to passing the policy. >> >> Other RIRs are free to implement whatever v6 PI policy they feel is >> appropriate for their region. I would support a globally standardized >> v6 PI policy along the lines of ARIN 2005-1. >> >> However, I would like to argue that if the new technical solution will >> benefit from the return of this address space, it is most likely not >> truly a solution, but, instead, another clever hack piled on top of >> the existing set of hacks. >> >> I suppose if someone found the magic bullet to make geotopological >> addressing really work, that might qualify. However, I have very low >> expectations in that area. >> >> Absent that, any true solution will involve making the size of the >> routing table independent of the number of PI (or even PA) blocks issued >> by the RIRs or will make the size of the routing table practically >> irrelevant. >> >> I know this isn't the easy solution, but, we need to look long and >> hard at the way we do things. I think that solving these problems >> is going to require a significant paradigm shift. Assuming that we >> can use IP addresses for both end system identification and for >> routing topology indicators is how we created this problem. I don't >> see solving it without breaking that assumption, at least at the >> interdomain level. >> >> >>> At this way, on the long-run, we will not have routing table >>> implications, but we allow now the people that want to move ahead only >>> if they have a multihoming solution doing so. >>> >> If you think there is a possible solution (a real solution, not just >> a hack that postpones the inevitable at the expense of usability >> like CIDR did), then I'd like to hear what you are thinking. >> >>> This 3-years time for getting a multihoming network back to the new >>> technical solution (once adopted) is enough time, I think (it could be >>> changed to 5 years if needed, or whatever), so nobody today see the >>> temporarily of the proposal as a showstopper to go for it now. >>> >> I think you underestimate the momentum and requirements of the modern >> enterprise if you believe that to be true. Any capability available >> in v4 that is not available on at least equal or better terms in v6 >> is a deterrent to v6 deployment. >> >> The ability to get permanent addresses which do not have to be returned >> when you switch providers or renumbered on a schedule determined by >> some external organization is a major example of such a capability. >> >> Owen >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From woody at pch.net Fri Apr 14 15:04:17 2006 From: woody at pch.net (Bill Woodcock) Date: Fri, 14 Apr 2006 12:04:17 -0700 (PDT) Subject: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: References: Message-ID: On Fri, 14 Apr 2006, JORDI PALET MARTINEZ wrote: > My proposal is having PI now everywhere, but those PI allocations > for multihoming should be temporary and those address blocks > returned to the RIRs after the new technical solution is > declared valid. "Temporary" and "experimental" go together. "Permanent" and "production" go together. Which do you want IPv6 to be? -Bill From memsvcs at arin.net Fri Apr 14 15:55:53 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 14 Apr 2006 15:55:53 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call Message-ID: <443FFE49.2000709@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_8.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, April 28, 2006. 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) ###*### Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement This proposal would amend the IPv6 address allocation policies (ARIN's NRPM, section 6) regarding the definition of the default size of End Site assignments and the threshold value for End Site allocation efficiency, no longer assuming the fixed values for End Site assignments established by RFC3177. Many references to "/48" will need to be replaced by "End Site assignment". for example, section 6.5.4.1 should be replaced as follows: 6.5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the End Site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document. also, section 6.9 will need to be replaced: 6.9. IPv6 Reassignments policy The size of IPv6 address assignments to End Sites is to be determined by the ISP/LIR. ISPs and LIRs may choose whether to make changes to their procedures for assigning address blocks to End Sites. The threshold End Site allocation efficiency level is between 20% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will need to operate address plans according to this target level of End Site allocation efficiency. there's a need to change ARIN NRPM IPv6 Utilization: The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation utilization criteria will reflect the use of a /56 as the unit quantity in the calculation of the ISP or LIR's end site allocation efficiency. Policy Rationale The current IPv6 Address Allocation and Assignment Policy (section 6 of ARIN's NRPM) indicates that end sites should be allocated a /48 as a uniform allocation unit if using more than one host or one subnet. This proposal alters the existing policy regarding LIR and ISP assignments to End Sites to allow the unit of assignment to be an LIR or ISP decision. In assessing the address utilization efficiency for ISPs or LIRs, the definition of an End Site for the purposes of the calculation of ISP or LIR End Site allocation efficiency, is to be made according to a /56 size. This measure, if undertaken generally by all RIRs, in conjunction with the further measures undertaken by the addressing community regarding increasing the HD ratio to 0.94, would increase the anticipated useful lifetime of IPv6 to encompass a period in excess of 100 years, in which case no further allocation policy changes would be anticipated. A more detailed rationale is available in Geoff Huston's presentation on the subject, at RIPE 50, which can be found at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-i pv6-roundtable-report.pdf From memsvcs at arin.net Fri Apr 14 15:59:21 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 14 Apr 2006 15:59:21 -0400 Subject: [ppml] Policy Proposal 2006-5: IPv4 Micro-allocations for anycast services (temporary) - Abandoned Message-ID: <443FFF19.8090001@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2006-5: IPv4 Micro-allocations for anycast services (temporary). It has determined that there is no community consensus in favor of the proposal and should thus be abandoned. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 12:00 Noon, Eastern Time, April 21, 2006. The current policy proposal text is provided below and is also available http://www.arin.net/policy/proposals/2006_5.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) ###*### Policy Proposal 2006-5: IPv4 Micro-allocations for anycast services (temporary) Policy statement Proposal type: new Policy term: temporary Policy statement: In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add: 4.4.2 Micro-allocations for anycast services - ARIN will make micro-allocations to organizations wishing to deploy anycast based services, provided they meet the following criteria: * All of the criteria normally required to receive IPv4 space, AND * The organization must have multiple (at least two) discrete multi-homed networks. * The organization must advertise directly allocated networks from each multi-homed site. Micro-allocations for anycast services will be no longer than a /24. These allocations will be made out of blocks reserved for micro-allocation purposes. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy is experimental, and is limited to 16 allocations and two years from adoption. In addition, organizations may receive no more than one microallocation under this policy. Policy Rationale There are an increasing number of anycast-based applications being offered by service providers and other organizations. Indeed, many basic infrastructure services (like the DNS root servers) are already anycast based. (See RFC 1546 for an authoritative discussion of anycast services.) It's worth noting that IPv6 has anycast built into the protocol itself. This is a sign that there is significant community interest in anycast as a technology, and highlights the lack of IPv4 allocation policy for anycast. Deployment of new services is severely hampered by current IPv4 allocation policies. For organizations that do not have legacy IP space, justifying a /22 to serve a handful of addresses is effectively impossible. As many ISPs also filter routes longer than /22, it is impractical to use a longer mask for any netblock that is utilized for an anycast service. This situation is also generally unfavorable to younger organizations, while giving older organizations that do have a surplus of legacy space a competitive advantage. In light of this, some organizations may simply lie about their addressing needs in order to convince an RIR or LIR that a /22 is required, when a much smaller network would suffice. This is not a behavior that should be encouraged by policy. The obvious answer is that a micro-allocation scheme needs to be created to allow organizations deploying anycast services to acquire a network of more appropriate size. It is also clear that a micro-allocation policy that makes it easier for organizations to acquire small netblocks may lead to additional improper allocations to organizations that simply wish to acquire additional small blocks of space. This policy proposal attempts to address that by requiring more stringent requirements for such allocations. A previous policy proposal (2005-6) is similar to this proposal, but with a few significant changes. There was significant negative feedback to that policy based on a couple of key difficulties, which this proposal attempts to address. The primary difficulty is that an anycast network looks much like a normal multihomed network from the outside. This led to the consensus belief that the earlier policy proposal would be abused by organizations that wouldn't otherwise qualify for address space. This proposal further restricts allocations such that only organizations that are already demonstratably multihomed with direct allocations can possibly qualify. Such organizations will typically have little use for a small allocation unless they really intend to use it for a specific purpose. In addition, this policy is marked as experimental and has a sunset clause, which will definitively prevent widespread abuse. It is hoped that operational experience will show that this policy is not seeing abuse, and it can later be modified to be permanent. In the event that this policy is widely abused, the total damage is limited and will be fixed in a relatively short time span. From memsvcs at arin.net Fri Apr 14 16:00:51 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 14 Apr 2006 16:00:51 -0400 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy - to be revised Message-ID: <443FFF73.4060608@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2006-1: Residential Customer Privacy and has determined that while there is no community consensus in favor of the proposal, there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The AC will work with the author of the proposal to make the community suggested revisions and return the proposal to the PPML for further discussion. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2006_1.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) ###*### Policy Proposal 2006-1: Residential Customer Privacy Policy statement Proposal type: modify (NRPM sections 4.2.3.7.6 and 6.5.5.1) Policy Term: permanent An organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private customer - XYZ Network', and the customer's entire address may be replaced with 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. NRPM Section 3.2 on Distributed Information Server Use Requirements (from policy proposal 2003-5) is also updated by striking the words "that includes displaying only the city, state, zip code, and country". Policy Rationale This policy allows for a residential customer's entire physical address to be suppressed, not just the street name and number. It also removes the US-centric phrases "state" and "zip code" from the NRPM, reflecting ARIN's broader service area. In many cases, a postal code or even a city name can identify few enough individuals, particularly considering the set of those likely to have their own IP assignments, that the intent of policy proposal 2003-3 is constructively defeated. From memsvcs at arin.net Fri Apr 14 16:02:14 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 14 Apr 2006 16:02:14 -0400 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised Message-ID: <443FFFC6.1060208@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2006-2: Micro-allocations for Internal Infrastructure and has determined that while there is no community consensus in favor of the proposal, there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The AC will work with the author of the proposal to make the community suggested revisions and return the proposal to the PPML for further discussion. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2006_2.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) ###*### Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure Policy statement: To replace section 6.10 6.10 Micro-allocation ARIN will make micro-allocations for critical infrastructure, and the RIRs and IANA as defined in the sub-sections below. These allocations will be no longer (more specific) than a IPv6 /48. Multiple allocations may be granted in certain situations. Micro-allocations MUST be provided from a specific range of addresses. ARIN will make a list of these blocks publicly available. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude organizations from requesting address space under other policies. 6.10.1 Micro-allocation for public exchange points Public Internet exchange point operators must provide justification for the micro-allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. 6.10.2 Micro-allocation for core DNS service providers Core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) must provide justification for the micro-allocation, including: name of core DNS server, location, ASN, and contact information. Core DNS server allocations MUST be allocated from the micro-allocation block. This block must be separate from the exchange point micro-allocation block and the internal infrastructure micro-allocation block. 6.10.3 Micro-allocation for internal infrastructure Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations MUST NOT be routed on global Internet. Internal infrastructure allocations MUST be allocated from specific blocks reserved only for this purpose. Policy Rationale Organizations that have only a single aggregate may require additional noncontiguous IP space for their internal infrastructure. This space should not be routed in the global Internet routing table. This will provide for the protection of internal infrastructure and support for applications that are sensitive to long convergence times like VoIP. It is important to note that the additional prefix allocation will not negatively impact the global routing table size as the additional prefix should not be routed. BGP Re-Convergence ISPs use BGP to originate their aggregate from multiple nodes within their infrastructure. They do this by routing their aggregate to discard on multiple devices. This ensures the Internet can reach the aggregate even when one or more nodes fail. If the next hop for a route is reachable via an aggregate that is in the routing table, then failures affecting the reachability of the next hop are subject to BGP hold timers, which can cause traffic to be dropped for the length of the bgp hold time (typically 3 minutes) The BGP re-convergence problem results when a multi-homed customer is announcing the same route to two different edge routers. When the edge router sourcing the primary path fails, the local address which is acting as the next hop, is removed from the IGP. If the next hop is still reachable through an aggregate or covering route, then the route will not be immediately invalidated in bgp. Until the bgp session with the failed device times out, traffic will be drawn to the device originating the aggregate, which is routed to discard and traffic will be dropped. After the bgp session with the failed device times out, the route will be removed and the next best route will be used. To minimize route failover time, you must ensure that the local addresses of the infrastructure, that act as next-hops for Internet routes, are NOT numbered with addresses that are a more specific than the aggregate. A detailed description of the problem space follows in the next three paragraphs. Having BGP next-hops that are not aggregated can cause faster convergence for customers who have multiple links to multiple routers of a single upstream AS. Take the case where a customer has two connections, link1 to edge-router1 and link2 to edge-router2, to a single upstream AS. The customer has an eBGP session with the loopback 2001:DB8::1/128 on edge-router1 and with loopback 2001:DB8::2/128 on edge-router2. The customer advertises a single prefix 2001:DB8:1000::/48 to both edge-router1 and edge-router2. The edge routers set next-hop self. The upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop of 2001:DB8::2. Assume the upstream ISP's entire network prefers the path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due to lower BGP MED value. Also assume that all of the address space owned by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge routers are a more specific of the aggregate /32. The upstream ISP has a pull-up route for 2001:DB8::/32 in the core of the network. This allows for the aggregation of all the more specific routes of 2001:DB8::/32. It insures the stability of the 2001:DB8::/32 announcement, while preventing an isolated edge router from advertising reachability to the network. If edge-router1 fails then 2001:DB8::1/128 will be immediately removed from the IGP. The preferred prefix for 2001:DB8:1000::/48 with a next-hop of 2001:DB8::1 will remain a valid bgp route and will continue to be the best path because 2001:DB8::1 is reachable through the pull-up route 2001:DB8::/32. Traffic will get blackholed for up to three minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 times out. Only then will traffic get forwarded to the next best path for 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::2. If instead the loopbacks of the edge routers (or any BGP protocol next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and there is no aggregate that covers the edge router loopbacks, then convergence will be much quicker. Assume that edge-router1 is using 2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up route is 2001:DB8::/32. In this case once edge-router1 fails, the IGP will detect it and remove 2001:408::1/128 from the IGP. This will invalidate the preferred path to 201:DB8:1000::/48 with a protocol next-hop of 2001:408:1 as there will be no route to the next hop (or even a less specific of this address). Once the path is invalidated, then the next best path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:408::2 will be declared best. Convergence times will be on the order of magnitude of the IGP failure detection and path re-calculation, typically less than one second. --------------- | Core Router |static route | |2001:DB8::/32 discard ----+------+--- | | / \ /-------------/ \--------\ / \ / /----------------------------\ \ | | | | ------+---+-- --+---+------ |Core Router|static route |Core Router|static route | |2001:DB8::/32 discard | |2001:DB8::/32 discard ---------+--- ---------+--- | | ---------+--------- ---------+--------- | edge-router1 | | edge-router2 | | 2001:DB8::1/128 | | 2001:DB8::2/128 | ---------+--------- ---------+--------- | | \ link1 link2 / \------------\ /---------/ \ / | | ----+---------+---- | CPE | | | ---------+--------- | LAN 2001:DB8:1000::/48 Internal Infrastructure Security Considerations Internal infrastructure could be numbered out of space that is not routed or reachable by the public Internet. This could be used to secure internal only services in a multi-layered approach by filtering direct network connections in the forwarding plane, and not routing the network in the global Internet routing table. Internal services which could take advantage of these layers of protection include: SNMP services, iBGP mesh, Out-of-Band management network(s), remote access to the network devices that make up the network in question. A layered security approach will help to prevent breaches in security via singular config management problems. Additionally, having all of the services out of an aggregate block will simplify the configuration management situation. In essence, this allows for a two tier approach of protecting infrastructure, both in the control plane by not routing the network, and in the forwarding plane by utilizing packet filters which are easily constructed and managed due to the uniqueness of the internal infrastructure block. Private Address Considerations Private addresses are not appropriate for a number of reasons. A public Internet network using private addresses internally may create confusion if trace routes contain private addresses. Additional problems may result due to wide spread filtering of private address space. ICMP messages may get dropped due to such a policy. This can lead to perceived odd behavior and make troubleshooting difficult. Additionally, the consequences of accidentally routing private ip space that is not globally unique, are potentially worse than if you accidentally announced globally unique space. DNS for private address space is today provided by blackhole-1.iana.org. and blackhole-2.iana.org. A provider who wants to maintain forward and reverse DNS sanity has to hijack those ip addresses to provide consistent DNS resolution. This will cause any users who's traffic transits that provider's network to also get 'inconsistent' answers with respect to the private address space in question. For management and troubleshooting purposes, it is important that infrastructure which provides Internet route reachability be numbered with addresses that resolve through DNS. Also, global uniqueness of addressing is important in minimizing renumbering efforts as organizations (and their networks) merge. RFC 4193 provides for neither of these needs. Timetable for implementation: Immediate From memsvcs at arin.net Fri Apr 14 16:03:57 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 14 Apr 2006 16:03:57 -0400 Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number - Last Call Message-ID: <4440002D.7040005@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-9: 4-Byte AS Number and has determined that there is community consensus in favor of the proposal, as edited below, to move it to last call. The AC removed the nomenclature and edited the terminology. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_9.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, April 28, 2006. 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) ###*### Policy Proposal 2005-9: 4-Byte AS Number Policy statement: This policy proposal nominates 3 dates for changes to the current AS Number allocation policy for the registry: - Commencing 1 January 2007 the registry will process applications that specifically request 32-bit only AS Numbers and allocate such AS numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, a 16-bit only AS Number will be allocated by the registry. - Commencing 1 January 2009 the registry will process applications that specifically request 16-bit only AS Numbers and allocate such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit only AS Number, a 32-bit only AS Number will be allocated by the registry. - Commencing 1 January 2010 the registry will cease to make any distinction between 16-bit only AS Numbers and 32-bit only AS Numbers, and will operate AS number allocations from an undifferentiated 32-bit AS Number allocation pool. Terminology "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - 4,294,967,295 "32-bit AS Numbers" refers to AS Numbers in the range 0 - 4,294,967,295 Policy Rationale Recent studies of AS number consumption rates indicate that the existing 16-bit pool of unallocated AS Numbers will be exhausted sometime in the period between 2010 and 2016, absent of any concerted efforts of recovery of already-allocated AS Numbers [1] [2]. Standardization work in the IETF has produced a document that is currently being submitted as a Proposed Standard that will expand the AS Number space to a 32-bit field [3]. It is noted that some advance period may be required by network operators to undertake the appropriate procedures relating to support of 32-bit AS numbers, and while no flag day is required in the transition to the longer AS Number field, it is recognised that a prudent course of action is to allow for allocation of these extended AS numbers well in advance of an anticipated 16-bit AS Number exhaustion date. This policy proposal details a set of actions and associated dates for RIR AS Number allocation policies to assist in an orderly transition to use of the 32-bit AS Number space. The essential attributes of this policy proposal are to facilitate the ease of transitional arrangements by equipment vendors, network managers and network operations staff, to provide the industry with some predictability in terms of dates and associated actions with respect to registry operational procedures for AS Number allocations. References [1] Daily AS Number Report, http://www.potaroo.net/tools/asns [2] ASNs MIA: A Comparison of RIR Statistics and RIS Reality, http://www.nanog.org/mtg-0510/wilhelm.html [3] BGP Support for Four-octet AS Number Space, draft-ietf-idr-as4bytes-12.txt Timetable for implementation: Procedures to support this proposal need to be implemented by 1 January 2007 From memsvcs at arin.net Fri Apr 14 16:09:52 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 14 Apr 2006 16:09:52 -0400 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites - Abandoned Message-ID: <44400190.9070006@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites. The AC abandoned 2006-4 after noting community preference for an edited version of Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 12:00 Noon, Eastern Time, April 21, 2006. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2006_4.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) ###*### Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites Policy statement Policy Proposal 2006-4, version 2 Add new subsection to the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct end site assignment, an organization must meet all of the following criteria: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv4; 4. have a direct assignment from ARIN of at least a IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 equivalent. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /48 out of a reserved /44. Organizations with multiple ASNs may be assigned a prefix large enough to permit a /48 to be assigned to each ASN. Direct Assignments shall be allocated from a separate super-block to allow for LIRs to filter. 6.5.8.3. Subsequent direct assignments to end sites Organization's assignment size may be increased to the next larger prefix (to a maximum of /44) when the organization demonstrates any of the following criteria: 1. 50% of the assigned /64 subnets are utilized 2. 50% of the /48 subnets are assigned and utilized to unique ASN assignments Organizations which request and can justify assignments larger than /44 shall qualify as LIRs and must make application for an allocation under policies applicable to an LIR, except that they shall be exempted from the requirement to assign addresses to other organizations. Only one direct assignment may be made to an end site organization under Section 6.5.8 Policy Rationale This policy is proposed as an alternative to the existing 2005-1 policy proposal. This policy is intended to be more conservative that the existing proposed 2005-1 policy. While this policy does allow PI assignments to end-sites, it limits the scope to current IPv4 holders with direct assignments. A more conservative policy is desirable as the first IPv6 PI policy. Current ARIN policy does not permit an end-site from obtaining a Provider Independent IPv6 address block directly from ARIN. There is currently no viable IPv6 multihoming method available for these end-sites. Shim6 & other methods have been proposed as a possible method to meet multihoming requirements. Today, no implementation or alternatives exist to ?traditional? IPv4 multihoming which announces unique address space from an ASN. The largest end-sites (corporations & content providers) have the greatest to gain and/or lose by not having an available method to multihome. While IPv6 provides for stateless auto configuration for end hosts, no new methods for renumbering the infrastructure are available. The cost and complexity of renumbering these large organizations makes it essential to provide stable address resources which are not assigned from a LIR. The lack of an end-site assignment policy is currently preventing the real planning and deployment of IPv6 networks in these organizations. Other policy proposals (2005-1) addressing this issue have been presented at the ARIN 15 & 16 meetings. This policy proposal attempts to address the issues that were raised on the ppml mailing list and at the public policy meetings for 2005-1. Specifically, the main issue surrounding the creation of consensus on this policy appears to be the criteria for which end-sites should be able to obtain an endsite assignment. Concerns have been raised about the creation of a new IPv6 ?swamp? by having a policy that is too lenient. This issue is addressed in the policy by limiting the endsite assignments to current organizations with a modest IPv4 assignment. The assignment of IPv4 resources is orthogonal to the assignment of IPv6 addresses. However, the use of existing IPv4 assignments and ARIN membership are postulated as an appropriate regulator for the initial assignments under an IPv6 endsite policy. It is reasonable to consider changes to the membership and IPv4 assignment requirements in the future. This review should be conducted after the endsite assignment policy has been in place long enough to understand the demand for endsite IPv6 assignments and the development of IPv6 networks have matured. This policy proposal does not attempt to address the assignment needs for endsites which currently do not have IPv4 assignments. From randy at psg.com Fri Apr 14 16:14:44 2006 From: randy at psg.com (Randy Bush) Date: Fri, 14 Apr 2006 10:14:44 -1000 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised References: <443FFFC6.1060208@arin.net> Message-ID: <17472.692.685697.785280@roam.psg.com> fwiw, after discussion with jason, i would support a more simple, direct, and clear proposal to the same end. randy From memsvcs at arin.net Fri Apr 14 16:18:42 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 14 Apr 2006 16:18:42 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call Message-ID: <444003A2.10005@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites and has determined that there is community consensus in favor of the proposal, as edited below, to move it to last call. The AC added the final sentence to section 6.5.8.2. as shown below. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_1.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, April 28, 2006. 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) ###*### Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites Policy statement: Add new subsection in section 6.5 of the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; and b) Qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. 6.5.8.3. Subsequent Assignment Size Additional assignments may be made when the need for additional subnets is justified. When possible assignments will be made from an adjacent address block. Policy Rationale In IPv4 policy there are three main types of organizations that addresses are delegated to. o ISP's receive allocations directly from ARIN or from other ISP's o End Users receive assignments from ISP's o Large and/or multihomed End Users receive assignments directly from ARIN. The third category is currently missing from IPv6 policy and this is believed to be severely hindering deployment by those organizations. In IPv6 policy-speak: o LIR's receive allocations directly from ARIN o End Sites receive assignments from LIR's This policy proposes: o Large and/or multihomed End Sites receive assignments directly from ARIN. This policy applies to organizations with networks that are large and/or multihomed. Like their IPv4 counterparts they do not make assignments to external organizations. They instead assign space internally to their own facilities. Similarly to IPv4 These internal assignments are not submitted to ARIN via swip/rwhois. For transition purposes an organization that qualifies for IPv4 space today is considered eligible, regardless of whether they were considered an ISP or End User under IPv4 policy. It is expected that the IPv6 only (non transition) requirements will be developed as experience is gained. It is recommended that these assignments be made from a separate address block set aside for this purpose and that at least a /44 be reserved around each assignment for possible expansion. One bit should be reserved around assignments /44 and larger. Timetable for implementation: immediately From memsvcs at arin.net Fri Apr 14 16:21:05 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 14 Apr 2006 16:21:05 -0400 Subject: [ppml] Policy Proposal 2006-3: Capturing Originations in Templates - to be revised Message-ID: <44400431.1070300@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2006-3: Capturing Originations in Templates and has determined that while there is no community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The AC will work with the author of the proposal to make the community suggested revisions and return the proposal to the PPML for further discussion. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2006_3.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) ###*### Policy Proposal 2006-3: Capturing Originations in Templates Policy statement: ARIN will collect an optional field in all IPv4 and IPv6 address block transactions (allocation and assignment requests, reallocation and reassignment actions, transfer and experimental requests). This additional field will be used to record a list of the ASes that the user permits to originate address prefixes within the address block. ARIN will produce a collection of the mappings from address blocks to ASes permitted to originate that address block, The collection will consist of a list where each entry will consist, at a minimum, of an address block, a list of AS numbers, and a tag indicating the type of delegation of the address block. This collection will be produced at least daily. ARIN will make the collected mappings from address blocks to AS numbers available for bulk transfer in one or more formats chosen at its own discretion, informed by the community's current needs. This data will not be subject to any redistribution restrictions -- it may be republished or repackaged it any form. Should ARIN choose to use WHOIS bulk transfer as the bulk form of data access required by this paragraph, the address block to AS mappings will not be subject to any redistribution restrictions, but the remainder of the WHOIS data will remain subject to the terms of the then-current AUP regarding bulk access to WHOIS data. ARIN may also make the collected or individual mappings from address blocks to AS numbers available in other forms, possibly query services, chosen at its own discretion, informed by the community's current needs. ARIN may require agreement to an acceptable use policy for access to the data in these forms. Policy Rationale Origination of prefixes by ASes that have no authority for the origination is a recurring problem in the Internet routing system. A list of authorized prefix originations would be beneficial to operators in * constructing routing filter lists to counter bogus originations, * interacting with customers requesting routing of a prefix, and * diagnosing routing problems. A list of authorized prefix originations is also the necessary first step for any known solution for securing the routing system. Prefix originations can be stored in routing registry RPSL route objects. However, the authority for addresses and for ASes belongs to the RIRs. There is presently no mechanism to translate ARIN's authority for number resources to an IRR. Furthermore, operators have been less than diligent in creating and maintaining route objects. Capturing the prefix origination authorization in number resource registrations with ARIN has two main goals: * benefit from the scrutiny with which ARIN verifies initial requests and authenticates subsequent transactions, and * inherit the operators' self-discipline in completing resource requests and transactions. As an additional benefit, this could take a step toward populating the IRR with data known to be accurate. The intended use of this data means that both query for individual entries and bulk access to a list of the collected entries, without restriction on redistribution, is required. This policy requires that the additional data be provided through the usual whois query service and some bulk access service that has no restrictions. It permits ARIN to provide the bulk access through the existing bulk whois service if the new additional data is not subject to the bulk whois AUP restrictions. The policy does not limit ARIN to providing only those two services (whois query and unrestricted bulk access); other additional services may be developed at ARIN's discretion. It is expected that entries in the list of collected entries will include at a minimum the present NetRange and NetType attributes, with a new attribute, perhaps named OriginatingASList, for the list of permitted originating ASes. This policy will presumably be incorporated into NRPM section 3.4. Timetable for implementation: Within sixty (60) days of approval. From jordi.palet at consulintel.es Fri Apr 14 16:23:02 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 14 Apr 2006 22:23:02 +0200 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <443FFE49.2000709@arin.net> Message-ID: Hi, While I don't agree with this proposal (I still believe a default /48 should be assigned to any end-site if is non-portable space), I would accept it, if the final text of the policy make sure that an end-site has the right to request to the LIR for being upgraded from the /64 or /56 to the /48 without the need for a detailed justification (as otherwise may go against the end-site right to privacy) and the end-site can get that upgrade at no extra recurrent costs (a setup fee is acceptable if it match real costs for that and a small recurrent cost which match the *real* cost for that space as paid to the RIR will be also acceptable). Is also important that the user upgrading from a /64 or /56 to a /48 don't need to renumber, so I will suggest that the ISP need to keep reserved the complete /48. For those that believe that reserving the /48 is a space waste, I will suggest to understand that this can be changed in the future (possible in hundreds of years, in my opinion) if we really come into a situation where we have to use the reserved space, even if that means renumbering some or all the end-sites (I'm considering that most of the end-sites that will fall into this situation will be residential customers). Renumbering once in hundreds of years should not be considered as a trouble, as most probably, residential users don't keep the same provider for so long time ... What I'm trying to avoid here is the situation that we have today which users being forced to NAT and a single dynamic IPv4 address, which can turn in a few years from now in something similar if you only get a /64 and need /56 or /48. Regards, Jordi > De: Member Services > Responder a: > Fecha: Fri, 14 Apr 2006 15:55:53 -0400 > Para: "ppml at arin.net" > Asunto: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment > and utilisation requirement - Last Call > > The ARIN Advisory Council (AC), acting under the provisions of the ARIN > Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy > proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation > requirement and has determined that there is community consensus in > favor of the proposal to move it to last call. The AC made this > determination at their meeting at the conclusion of the ARIN Public > Policy meeting on April 11, 2006. The results of the AC meeting were > reported by the Chair of the AC at the member meeting. This report can > be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html > > The policy proposal text is provided below and is also available at > http://www.arin.net/policy/proposals/2005_8.html > > Comments are encouraged. All comments should be provided to > ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, > April 28, 2006. > > 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) > > > ###*### > Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and > utilisation requirement > > This proposal would amend the IPv6 address allocation policies (ARIN's > NRPM, section 6) regarding the definition of the default size of End > Site assignments and the threshold value for End Site allocation > efficiency, no longer assuming the fixed values for End Site assignments > established by RFC3177. Many references to "/48" will need to be > replaced by "End Site assignment". > > for example, section 6.5.4.1 should be replaced as follows: > > 6.5.4.1. Assignment address space size > > End Users are assigned an End Site assignment from their LIR or ISP. The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /64 (when only one subnet is > anticipated for the End Site) up to the normal maximum of /48, except in > cases of extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > - /64 when it is known that one and only one subnet is needed > > - /56 for small sites, those expected to need only a few subnets over > the next 5 years. > > - /48 for larger sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > RIRs/NIRs are not concerned about which address size an LIR/ISP actually > assigns. Accordingly, RIRs/NIRs will not request the detailed information on > IPv6 user networks as they did in IPv4, except for the cases described > in Section 6.4.4 and for the purposes of measuring utilization as > defined in this document. > > also, section 6.9 will need to be replaced: > > 6.9. IPv6 Reassignments policy > > The size of IPv6 address assignments to End Sites is to be determined by > the ISP/LIR. > > ISPs and LIRs may choose whether to make changes to their procedures for > assigning address blocks to End Sites. The threshold End Site allocation > efficiency level is between 20% to 50% for most ISPs and LIRs when based > on a 0.94 HD Ratio. ISPs and LIRs will need to operate address plans > according to this target level of End Site allocation efficiency. > > there's a need to change ARIN NRPM IPv6 Utilization: > > The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation > utilization criteria will reflect the use of a /56 as the unit quantity > in the calculation of the ISP or LIR's end site allocation efficiency. > > Policy Rationale > > The current IPv6 Address Allocation and Assignment Policy (section 6 of > ARIN's NRPM) indicates that end sites should be allocated a /48 as a > uniform allocation unit if using more than one host or one subnet. > > This proposal alters the existing policy regarding LIR and ISP > assignments to End Sites to allow the unit of assignment to be an LIR or > ISP decision. > > In assessing the address utilization efficiency for ISPs or LIRs, the > definition of an End Site for the purposes of the calculation of ISP or > LIR End Site allocation efficiency, is to be made according to a /56 size. > > This measure, if undertaken generally by all RIRs, in conjunction with > the further measures undertaken by the addressing community regarding > increasing the HD ratio to 0.94, would increase the anticipated useful > lifetime of IPv6 to encompass a period in excess of 100 years, in which > case no further allocation policy changes would be anticipated. > > A more detailed rationale is available in Geoff Huston's presentation on > the subject, at RIPE 50, which can be found at: > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-i > pv6-roundtable-report.pdf > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jdhoule at att.com Fri Apr 14 16:30:20 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Fri, 14 Apr 2006 15:30:20 -0500 Subject: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: <230986FA51D4397BB247CFCD@imac-en0.delong.sj.ca.us> Message-ID: Owen: I don't understand what you mean by property 1... Do you mean that the solution should have little to no impact on the routing table size? Joe Houle -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, April 14, 2006 2:54 PM ... In my opinion, to be a solution, rather than a hack, it must have the following properties: 1. Routing table growth is either unconstrained or unrelated to prefix deaggregation. Owen From sleibrand at internap.com Fri Apr 14 16:35:25 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 14 Apr 2006 16:35:25 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: On 04/14/06 at 10:23pm +0200, JORDI PALET MARTINEZ Hi, > > While I don't agree with this proposal (I still believe a default /48 should > be assigned to any end-site if is non-portable space), Why? Do you think that a site with 65,000 subnets can claim to just be a non-business residential customer? > I would accept it, if the final text of the policy make sure that an > end-site has the right to request to the LIR for being upgraded from the > /64 or /56 to the /48 without the need for a detailed justification (as > otherwise may go against the end-site right to privacy) and the end-site > can get that upgrade at no extra recurrent costs (a setup fee is > acceptable if it match real costs for that and a small recurrent cost > which match the *real* cost for that space as paid to the RIR will be > also acceptable). This sounds to me like something *way* outside of ARIN's authority. > Is also important that the user upgrading from a /64 or /56 to a /48 > don't need to renumber, so I will suggest that the ISP need to keep > reserved the complete /48. > > For those that believe that reserving the /48 is a space waste, I will > suggest to understand that this can be changed in the future (possible in > hundreds of years, in my opinion) if we really come into a situation where > we have to use the reserved space, even if that means renumbering some or > all the end-sites (I'm considering that most of the end-sites that will fall > into this situation will be residential customers). Renumbering once in > hundreds of years should not be considered as a trouble, as most probably, > residential users don't keep the same provider for so long time ... > > What I'm trying to avoid here is the situation that we have today which > users being forced to NAT and a single dynamic IPv4 address, which can turn > in a few years from now in something similar if you only get a /64 and need > /56 or /48. Do you think that a home network will need more than a million host addresses within "a few years from now"? I don't. I do agree that home users may want to run more than one subnet, and may want more than one /64. Therefore I agree with the guideline that /64's should only be given out when it is known a priori that one and only one subnet is needed, and that a /56 should be given out otherwise. However, I think that anyone who actually needs a /48 really should be considered a business customer, not a residential customer. -Scott From dlw+arin at tellme.com Fri Apr 14 16:42:43 2006 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 14 Apr 2006 13:42:43 -0700 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: <20060414204243.GO29385@shell01.corp.tellme.com> On Fri, Apr 14, 2006 at 04:35:25PM -0400, Scott Leibrand wrote: > I do agree that home users may want to run more than one subnet, and may > want more than one /64. Therefore I agree with the guideline that /64's > should only be given out when it is known a priori that one and only one > subnet is needed, and that a /56 should be given out otherwise. However, > I think that anyone who actually needs a /48 really should be considered a > business customer, not a residential customer. I have to admint that I'm very puzzled by the ongoing effort to keep masks bounded by "interesting" numbers of bits. While the vast majority of home users will be fine with a /64, how many of the remainder really will ever need a /56? I suspect that the majority not sufficiently serviced by a /64 would be fine with a /63 or /62. Why assign all of that extra space? It seems to me that you can fit a lot of /62s into a single /56. (Am I just missing something obvious here?) Oh, and I agree that anyone who can justify a /48 is definitely a business. -David From jordi.palet at consulintel.es Fri Apr 14 17:22:28 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 14 Apr 2006 23:22:28 +0200 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: Message-ID: Hi Scott, See below, in-line. Regards, Jordi > De: Scott Leibrand > Responder a: > Fecha: Fri, 14 Apr 2006 16:35:25 -0400 (EDT) > Para: JORDI PALET MARTINEZ > CC: "ppml at arin.net" > Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 > assignment and utilisation requirement - Last Call > > On 04/14/06 at 10:23pm +0200, JORDI PALET MARTINEZ > >> Hi, >> >> While I don't agree with this proposal (I still believe a default /48 should >> be assigned to any end-site if is non-portable space), > > Why? Do you think that a site with 65,000 subnets can claim to just be a > non-business residential customer? Yes I know from current research of services and products that will be in the market in the next few years, that residential customers will need more than 256 subnets. I'm not so convinced about 65.000 subnets, but I'm given the choice in between 256 subnets or 65.000 subnets, I much prefer to be sure than became short. And I'm still talking about homes (smart homes if you want to say), so residential customers, not business customers. However, there is more and more people working from their home, may be you want to consider them a special case also ;-) > >> I would accept it, if the final text of the policy make sure that an >> end-site has the right to request to the LIR for being upgraded from the >> /64 or /56 to the /48 without the need for a detailed justification (as >> otherwise may go against the end-site right to privacy) and the end-site >> can get that upgrade at no extra recurrent costs (a setup fee is >> acceptable if it match real costs for that and a small recurrent cost >> which match the *real* cost for that space as paid to the RIR will be >> also acceptable). > > This sounds to me like something *way* outside of ARIN's authority. I'm not sure in the case of ARIN, but in other registries, the charging by LIRs to end-customers is expected to be to cover their administrative costs, not to make money out of the addresses and ASNs, which are a human property. On the other way around, the LIRs need to understand that charging for the addresses at the end is against their business. I've already talked about this in other occasions. In Spain you pay typically 12 Euros for each IPv4 address per month (while the cost of the ADSL line is now 20 Euros, including free national phone calls). Obviously the ISPs aren't making any *real* business, because almost none of the 4.5 million broadband users in the country pay for that. However, this makes almost impossible to the ISPs to deploy easily new services and applications which can be charged for and thus make much more profit than with the 12 Euros per address (not to say the extra cost of running NAT and providing support for the problems caused by NAT). Unfortunately, most of the ISPs, still don't see that and I doubt that in the short term they will see it. As said, I want to make sure that users don't end up paying for that and ISPs realize that the business is in the added value services and applications. Is the only way IPv6 will succeed. But even if you don't agree with me about the cost issue, may be you agree that the end-user don't need to justify why he needs more subnets and has the right to keep his privacy. This is clearly part of ARIN authority. Same with avoiding the renumbering, otherwise, we are unfair defining policy that avoid renumbering to LIRs, right ? > >> Is also important that the user upgrading from a /64 or /56 to a /48 >> don't need to renumber, so I will suggest that the ISP need to keep >> reserved the complete /48. >> >> For those that believe that reserving the /48 is a space waste, I will >> suggest to understand that this can be changed in the future (possible in >> hundreds of years, in my opinion) if we really come into a situation where >> we have to use the reserved space, even if that means renumbering some or >> all the end-sites (I'm considering that most of the end-sites that will fall >> into this situation will be residential customers). Renumbering once in >> hundreds of years should not be considered as a trouble, as most probably, >> residential users don't keep the same provider for so long time ... >> >> What I'm trying to avoid here is the situation that we have today which >> users being forced to NAT and a single dynamic IPv4 address, which can turn >> in a few years from now in something similar if you only get a /64 and need >> /56 or /48. > > Do you think that a home network will need more than a million host > addresses within "a few years from now"? I don't. Is not a question of how many addresses. It may be the case that we only use a few addresses of each subnet. That's fine, is part of the design of IPv6 that we accepted, which has lots of advantages, like the capability to run auto-configuration, privacy, CGAs, and for sure more to come. > > I do agree that home users may want to run more than one subnet, and may > want more than one /64. Therefore I agree with the guideline that /64's > should only be given out when it is known a priori that one and only one Which I will interpret as almost never a /64 should be given out (may be only for a cellular phone and only if it is not connecting other devices with other interfaces, otherwise is a mobile router). > subnet is needed, and that a /56 should be given out otherwise. However, > I think that anyone who actually needs a /48 really should be considered a > business customer, not a residential customer. As said, this is no longer the case if we look to the situation that can be expected in a very few years. > > -Scott > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owen at delong.com Fri Apr 14 17:42:33 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Apr 2006 14:42:33 -0700 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: Jordi, The only problem I see with your proposal here is that requiring the ISP to reserve a /48 means that the ISPs costs are the same whether the end site accepts a /64, a /56, or a /48. As such, there would be absolutely no benefit whatsoever to allowing smaller assignments. In essence, the cost structure and requirements you propose would nullify the intent of 2005-8. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Fri Apr 14 17:53:04 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Apr 2006 14:53:04 -0700 Subject: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: References: Message-ID: --On April 14, 2006 3:30:20 PM -0500 "Houle, Joseph D (Joe), CMO" wrote: > Owen: > I don't understand what you mean by property 1... Do you mean that > the solution should have little to no impact on the routing table size? > I mean that the solution will involve a routing table which has one of the following two properties: 1. Growth in the number of prefixes on the internet is not arithmetically tied to growth in the routing table. 2. The algorithm or method used is designed in such a way that existing hardware could handle a routing table supporting any conceivable value of assigned prefixes (which I would put somewhere around 1e10). One possible way to achieve this is the use of an ID/Locator split in the Interdomain arena. Thus, since the "global" routing table would not contain prefixes, it would meet property 1 above. I can't envision a way that property 2 could be accomplished, but, I accept that there is no possibility that I can envision all possible solutions. My attempt is to state requirements. I believe that any true solution will have to meet one of those 2 requirements or it will suffer from the same problems as the current solution. You may be able to change the scale at which the problems occur, but, without one of those 2 solutions, the problems still occur at some scale. In reality, solution 2 is a pathological case of changing the scale, but, involves essentially changing the scale to "the size of the internet". Owen > Joe Houle > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Owen DeLong > Sent: Friday, April 14, 2006 2:54 PM > ... > In my opinion, to be a solution, rather than a hack, it must > have the following properties: > > 1. Routing table growth is either unconstrained or > unrelated > to prefix deaggregation. > > Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Fri Apr 14 18:01:02 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Apr 2006 15:01:02 -0700 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <20060414204243.GO29385@shell01.corp.tellme.com> References: <20060414204243.GO29385@shell01.corp.tellme.com> Message-ID: > I have to admint that I'm very puzzled by the ongoing effort to keep > masks bounded by "interesting" numbers of bits. > > While the vast majority of home users will be fine with a /64, how many > of the remainder really will ever need a /56? I suspect that the > majority not sufficiently serviced by a /64 would be fine with a /63 or > /62. Why assign all of that extra space? It seems to me that you can > fit a lot of /62s into a single /56. (Am I just missing something > obvious here?) > Yes... short answer: ip6.arpa. Long answer: v6 has enough space that even at the /48 assignment boundary, we're a long way off from an addressing crisis. However, allowing a /56 boundary for small business and residential customers could stave that crisis off, essentially indefinitely. Reverse DNS assignments for small networks in the V4 world are a kludge. Let's not repeat that in v6. There's just no point in worrying about sub-nibble boundaries, and probably little point in worrying about sub-octet boundaries. OTOH, I kind of like the idea of an ICMP "what's your name" protocol, but, I don't believe that would completely eliminate the need or desire for ip6.arpa or in-addr.arpa. > Oh, and I agree that anyone who can justify a /48 is definitely a > business. > I bet if Clan Campbell wanted to form their own family internet and build a series of links between households to facilitate a family network with a few points where it connected to the internet, you could argue that a /48 was justified and that it wasn't technically a business. However, I would agree that is a corner case. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jordi.palet at consulintel.es Fri Apr 14 18:28:40 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 15 Apr 2006 00:28:40 +0200 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: Message-ID: Hi Owen, Yes, I know, it may seem so, but is not the case. Actually for the ISP is cheaper to keep a flat infrastructure, having everything with /48. I also don't think the RIR fees will make a difference, at least not in the short/medium term for that, but of course, this is something that is yet not clear. In theory the only reason for 2005-8 is to conserve space. If that's the case, then what I'm proposing will make it, as the reserved /48 which is not being used, will be available if we really reach the point where we used all the non-reserved space. A small policy modification at that point, will allow the ISPs to forget about those /48 reservations that have not been claimed by end-users. I think we should remember that if we agree to change the HD-ratio, the figures that Tony has calculated, and I think are realistic, give IPv6 a life of 480 years. Anyone still believe that IP (IPv4 or IPv6, doesn't matter for this case), will be still available in 200 years ? So ? Regards, Jordi > De: Owen DeLong > Responder a: > Fecha: Fri, 14 Apr 2006 14:42:33 -0700 > Para: , "ppml at arin.net" > Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 > assignment and utilisation requirement - Last Call > > Jordi, > The only problem I see with your proposal here is that requiring the > ISP to reserve a /48 means that the ISPs costs are the same whether the end > site accepts a /64, a /56, or a /48. As such, there would be absolutely no > benefit whatsoever to allowing smaller assignments. In essence, the cost > structure and requirements you propose would nullify the intent of 2005-8. > > Owen ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From michel at arneill-py.sacramento.ca.us Fri Apr 14 18:57:54 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 14 Apr 2006 15:57:54 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call Message-ID: I support 2005-1. Michel. -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Member Services Sent: Friday, April 14, 2006 1:19 PM To: ppml at arin.net Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites and has determined that there is community consensus in favor of the proposal, as edited below, to move it to last call. The AC added the final sentence to section 6.5.8.2. as shown below. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_1.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, April 28, 2006. 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) ###*### Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites Policy statement: Add new subsection in section 6.5 of the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; and b) Qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. 6.5.8.3. Subsequent Assignment Size Additional assignments may be made when the need for additional subnets is justified. When possible assignments will be made from an adjacent address block. Policy Rationale In IPv4 policy there are three main types of organizations that addresses are delegated to. o ISP's receive allocations directly from ARIN or from other ISP's o End Users receive assignments from ISP's o Large and/or multihomed End Users receive assignments directly from ARIN. The third category is currently missing from IPv6 policy and this is believed to be severely hindering deployment by those organizations. In IPv6 policy-speak: o LIR's receive allocations directly from ARIN o End Sites receive assignments from LIR's This policy proposes: o Large and/or multihomed End Sites receive assignments directly from ARIN. This policy applies to organizations with networks that are large and/or multihomed. Like their IPv4 counterparts they do not make assignments to external organizations. They instead assign space internally to their own facilities. Similarly to IPv4 These internal assignments are not submitted to ARIN via swip/rwhois. For transition purposes an organization that qualifies for IPv4 space today is considered eligible, regardless of whether they were considered an ISP or End User under IPv4 policy. It is expected that the IPv6 only (non transition) requirements will be developed as experience is gained. It is recommended that these assignments be made from a separate address block set aside for this purpose and that at least a /44 be reserved around each assignment for possible expansion. One bit should be reserved around assignments /44 and larger. Timetable for implementation: immediately _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From michel at arneill-py.sacramento.ca.us Fri Apr 14 18:59:30 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 14 Apr 2006 15:59:30 -0700 Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number - Last Call Message-ID: I support 2005-9 Michel. -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Member Services Sent: Friday, April 14, 2006 1:04 PM To: ppml at arin.net Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number - Last Call The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-9: 4-Byte AS Number and has determined that there is community consensus in favor of the proposal, as edited below, to move it to last call. The AC removed the nomenclature and edited the terminology. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_9.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, April 28, 2006. 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) ###*### Policy Proposal 2005-9: 4-Byte AS Number Policy statement: This policy proposal nominates 3 dates for changes to the current AS Number allocation policy for the registry: - Commencing 1 January 2007 the registry will process applications that specifically request 32-bit only AS Numbers and allocate such AS numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, a 16-bit only AS Number will be allocated by the registry. - Commencing 1 January 2009 the registry will process applications that specifically request 16-bit only AS Numbers and allocate such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit only AS Number, a 32-bit only AS Number will be allocated by the registry. - Commencing 1 January 2010 the registry will cease to make any distinction between 16-bit only AS Numbers and 32-bit only AS Numbers, and will operate AS number allocations from an undifferentiated 32-bit AS Number allocation pool. Terminology "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - 4,294,967,295 "32-bit AS Numbers" refers to AS Numbers in the range 0 - 4,294,967,295 Policy Rationale Recent studies of AS number consumption rates indicate that the existing 16-bit pool of unallocated AS Numbers will be exhausted sometime in the period between 2010 and 2016, absent of any concerted efforts of recovery of already-allocated AS Numbers [1] [2]. Standardization work in the IETF has produced a document that is currently being submitted as a Proposed Standard that will expand the AS Number space to a 32-bit field [3]. It is noted that some advance period may be required by network operators to undertake the appropriate procedures relating to support of 32-bit AS numbers, and while no flag day is required in the transition to the longer AS Number field, it is recognised that a prudent course of action is to allow for allocation of these extended AS numbers well in advance of an anticipated 16-bit AS Number exhaustion date. This policy proposal details a set of actions and associated dates for RIR AS Number allocation policies to assist in an orderly transition to use of the 32-bit AS Number space. The essential attributes of this policy proposal are to facilitate the ease of transitional arrangements by equipment vendors, network managers and network operations staff, to provide the industry with some predictability in terms of dates and associated actions with respect to registry operational procedures for AS Number allocations. References [1] Daily AS Number Report, http://www.potaroo.net/tools/asns [2] ASNs MIA: A Comparison of RIR Statistics and RIS Reality, http://www.nanog.org/mtg-0510/wilhelm.html [3] BGP Support for Four-octet AS Number Space, draft-ietf-idr-as4bytes-12.txt Timetable for implementation: Procedures to support this proposal need to be implemented by 1 January 2007 _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From michel at arneill-py.sacramento.ca.us Fri Apr 14 19:02:28 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 14 Apr 2006 16:02:28 -0700 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call Message-ID: I support 2005-8 Michel. -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Member Services Sent: Friday, April 14, 2006 12:56 PM To: ppml at arin.net Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_8.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, April 28, 2006. 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) ###*### Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement This proposal would amend the IPv6 address allocation policies (ARIN's NRPM, section 6) regarding the definition of the default size of End Site assignments and the threshold value for End Site allocation efficiency, no longer assuming the fixed values for End Site assignments established by RFC3177. Many references to "/48" will need to be replaced by "End Site assignment". for example, section 6.5.4.1 should be replaced as follows: 6.5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the End Site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document. also, section 6.9 will need to be replaced: 6.9. IPv6 Reassignments policy The size of IPv6 address assignments to End Sites is to be determined by the ISP/LIR. ISPs and LIRs may choose whether to make changes to their procedures for assigning address blocks to End Sites. The threshold End Site allocation efficiency level is between 20% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will need to operate address plans according to this target level of End Site allocation efficiency. there's a need to change ARIN NRPM IPv6 Utilization: The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation utilization criteria will reflect the use of a /56 as the unit quantity in the calculation of the ISP or LIR's end site allocation efficiency. Policy Rationale The current IPv6 Address Allocation and Assignment Policy (section 6 of ARIN's NRPM) indicates that end sites should be allocated a /48 as a uniform allocation unit if using more than one host or one subnet. This proposal alters the existing policy regarding LIR and ISP assignments to End Sites to allow the unit of assignment to be an LIR or ISP decision. In assessing the address utilization efficiency for ISPs or LIRs, the definition of an End Site for the purposes of the calculation of ISP or LIR End Site allocation efficiency, is to be made according to a /56 size. This measure, if undertaken generally by all RIRs, in conjunction with the further measures undertaken by the addressing community regarding increasing the HD ratio to 0.94, would increase the anticipated useful lifetime of IPv6 to encompass a period in excess of 100 years, in which case no further allocation policy changes would be anticipated. A more detailed rationale is available in Geoff Huston's presentation on the subject, at RIPE 50, which can be found at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-w ed-i pv6-roundtable-report.pdf _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From lea.roberts at stanford.edu Fri Apr 14 20:30:45 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Fri, 14 Apr 2006 17:30:45 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <20060414204243.GO29385@shell01.corp.tellme.com> Message-ID: hi David - On Fri, 14 Apr 2006, David Williamson wrote: > On Fri, Apr 14, 2006 at 04:35:25PM -0400, Scott Leibrand wrote: > > I do agree that home users may want to run more than one subnet, and may > > want more than one /64. Therefore I agree with the guideline that /64's > > should only be given out when it is known a priori that one and only one > > subnet is needed, and that a /56 should be given out otherwise. However, > > I think that anyone who actually needs a /48 really should be considered a > > business customer, not a residential customer. > > I have to admint that I'm very puzzled by the ongoing effort to keep > masks bounded by "interesting" numbers of bits. as I said in the presentation at ARIN XVII, this policy was conceived to provide for assignments of less than the /48 which was specified by RFC3177. Geoff's analysis says that, contrary to the belief of the IETF, assigning /48s to all could lead to premature exhaustion of the IPv6 address space. Moving to /56 for small sites was proposed as sufficient to protect against that problem. ISP feedback was it was not for the RIRs to decree what assignment policy an ISP/LIR should have, so the policy was updated in that respect, with some "suggestions" as to assignment sizes. The interesting bit boundaries are nibbles (4-bit multiples) since they define the delegation boudaries for IPv6 reverse delegation. As Owen has stated in another post, it seems reasonable to avoid the added complication of not keeping that clean this time around. > While the vast majority of home users will be fine with a /64, how many > of the remainder really will ever need a /56? I suspect that the > majority not sufficiently serviced by a /64 would be fine with a /63 or > /62. Why assign all of that extra space? It seems to me that you can > fit a lot of /62s into a single /56. (Am I just missing something > obvious here?) there is a real need to encourage generous assignment sizes. there is no shortage of IPv6 addresses for centuries as long as the shift down to /56 is accomplished. it is much more important to make sure that users have room to grow as no doubt there will be ways of using addressing in the future, allowed by IPv6, that we can't conceive of in today's technology. this policy is just trying to allow for less wasteful generosity than RFC3177. it is also trying to continue to promote the mind shift away from the conservative assignment policies required by the limited address space available in IPv4. as we also discussed at the ARIN XVII meeting, it would be useful for some group to define guidelines for assignment policy that would clarify the issues you raise. it seems that in ARIN policy is not the correct place yet no other group comes to mind. anyway, as a rough suggestion, I would say that end sites should get 4 to 8 times as much address space assigned as they think they might use using today's networking techniques. I hope that gives you some answers... :-) /Lea From christopher.morrow at gmail.com Fri Apr 14 20:42:11 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 14 Apr 2006 20:42:11 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: <75cb24520604141742s2d047b12gca2843e05cc0122d@mail.gmail.com> On 4/14/06, JORDI PALET MARTINEZ wrote: > Hi Owen, > > Yes, I know, it may seem so, but is not the case. > > Actually for the ISP is cheaper to keep a flat infrastructure, having > everything with /48. > based on which cost model? I can assign a single /48 to a BRAS and push /64's to end bridge devices... that seems 'cheaper' to me in terms of route-bloat in my core... Just curious as to where your figure comes from really, thanks. in general I really don't support this fictional 'classful ipv6': /32 = provider, /48 = customer, /64 = LAN. I believe it's wasteful and unnecessary. Especially in a world that's been pushed to smaller subnets/broadcast domains and an increase of bandwidth per LAN required. there are some interesting contradictions in the ages-old v6 address planning and current world networking... -Chris From bicknell at ufp.org Sat Apr 15 00:23:31 2006 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 15 Apr 2006 00:23:31 -0400 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Message-ID: <20060415042331.GA74377@ussenterprise.ufp.org> This message was cross posted to a large number of lists. I would like to make the root of the discussion clear, without taking an opinion. This link is the original message, best I can tell. Hopefully from there each individual on this message can tell how they came to receive it. http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00162.html Please go back to the header as well. Lists from several different organizations have been CC'ed, and each will have their own opinion. All are available on the web. A well informed reply is the best reply. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Sat Apr 15 02:35:33 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Apr 2006 23:35:33 -0700 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: <639B560272E2C6318C662821@imac-en0.delong.sj.ca.us> --On April 15, 2006 12:28:40 AM +0200 JORDI PALET MARTINEZ wrote: > Hi Owen, > > Yes, I know, it may seem so, but is not the case. > > Actually for the ISP is cheaper to keep a flat infrastructure, having > everything with /48. > I think that's variable from an infrastructure perspective, however, from an RIR fees perspective, if each /32 costs $x, then, each /48 costs either $x/65536 or $x/n where n is the number of customers you can put into said /48. In the case where n>65536, the cost per /48 is reduced. > I also don't think the RIR fees will make a difference, at least not in > the short/medium term for that, but of course, this is something that is > yet not clear. > Obviously at the moment when RIRs are waiving v6 fees, this is true. However, given that a /32 costs $2,250/year and a /31 costs $4,500 per year, if I can multiply the customer count in the first /32 by as little as 2, it is useful. > In theory the only reason for 2005-8 is to conserve space. If that's the > case, then what I'm proposing will make it, as the reserved /48 which is > not being used, will be available if we really reach the point where we > used all the non-reserved space. A small policy modification at that > point, will allow the ISPs to forget about those /48 reservations that > have not been claimed by end-users. > With the possible exception of free address pool fragmentation, I would agree with you to a certain extent. The only other problem I see is that it won't be perceived as an issue until several ISPs have grabbed onto multpile /32s with lots of empty reserved space and some other ISP(s) need an unavailable /32. I agree this is a long way off, but, in terms of IPv6 potential useful life, a long way off might not be far enough. > I think we should remember that if we agree to change the HD-ratio, the > figures that Tony has calculated, and I think are realistic, give IPv6 a > life of 480 years. Anyone still believe that IP (IPv4 or IPv6, doesn't > matter for this case), will be still available in 200 years ? So ? > I've seen numbers (I think from Geoff Huston) that said it was more like 60 years. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Sat Apr 15 02:41:06 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Apr 2006 23:41:06 -0700 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: > as we also discussed at the ARIN XVII meeting, it would be useful for > some group to define guidelines for assignment policy that would clarify > the issues you raise. it seems that in ARIN policy is not the correct > place yet no other group comes to mind. anyway, as a rough suggestion, I > would say that end sites should get 4 to 8 times as much address space > assigned as they think they might use using today's networking techniques. > Perhaps we need a BCP track within ARIN for number resource utilization. A process similar to, but, potentially a bit less formal than, the IRPEP which would be used to develop "Recommended Practices for Number Resource Allocation, Assignment, and Utilization". I agree this doesn't belong in policy, but, I do think that ARIN might be the right body to coalesce such information, at least on a regional basis. Eventually, perhaps parallel capabilities would develop in the other RIRs supporting an IANA based point to coalesce them on a global basis where appropriate. Owen > I hope that gives you some answers... :-) /Lea > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From sleibrand at internap.com Sat Apr 15 09:14:44 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 15 Apr 2006 09:14:44 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: A meta-question: If you end up needing more than 256 subnets for your house, and have a /56 or even a /64, can you make your subnets /65's, /66's, etc? -Scott On 04/14/06 at 11:22pm +0200, JORDI PALET MARTINEZ Hi Scott, > > See below, in-line. > > Regards, > Jordi > > > > > > De: Scott Leibrand > > Responder a: > > Fecha: Fri, 14 Apr 2006 16:35:25 -0400 (EDT) > > Para: JORDI PALET MARTINEZ > > CC: "ppml at arin.net" > > Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 > > assignment and utilisation requirement - Last Call > > > > On 04/14/06 at 10:23pm +0200, JORDI PALET MARTINEZ > > > > >> Hi, > >> > >> While I don't agree with this proposal (I still believe a default /48 should > >> be assigned to any end-site if is non-portable space), > > > > Why? Do you think that a site with 65,000 subnets can claim to just be a > > non-business residential customer? > > Yes I know from current research of services and products that will be in > the market in the next few years, that residential customers will need more > than 256 subnets. > > I'm not so convinced about 65.000 subnets, but I'm given the choice in > between 256 subnets or 65.000 subnets, I much prefer to be sure than became > short. > > And I'm still talking about homes (smart homes if you want to say), so > residential customers, not business customers. However, there is more and > more people working from their home, may be you want to consider them a > special case also ;-) > > > > >> I would accept it, if the final text of the policy make sure that an > >> end-site has the right to request to the LIR for being upgraded from the > >> /64 or /56 to the /48 without the need for a detailed justification (as > >> otherwise may go against the end-site right to privacy) and the end-site > >> can get that upgrade at no extra recurrent costs (a setup fee is > >> acceptable if it match real costs for that and a small recurrent cost > >> which match the *real* cost for that space as paid to the RIR will be > >> also acceptable). > > > > This sounds to me like something *way* outside of ARIN's authority. > > I'm not sure in the case of ARIN, but in other registries, the charging by > LIRs to end-customers is expected to be to cover their administrative costs, > not to make money out of the addresses and ASNs, which are a human property. > > On the other way around, the LIRs need to understand that charging for the > addresses at the end is against their business. I've already talked about > this in other occasions. In Spain you pay typically 12 Euros for each IPv4 > address per month (while the cost of the ADSL line is now 20 Euros, > including free national phone calls). Obviously the ISPs aren't making any > *real* business, because almost none of the 4.5 million broadband users in > the country pay for that. However, this makes almost impossible to the ISPs > to deploy easily new services and applications which can be charged for and > thus make much more profit than with the 12 Euros per address (not to say > the extra cost of running NAT and providing support for the problems caused > by NAT). > > Unfortunately, most of the ISPs, still don't see that and I doubt that in > the short term they will see it. As said, I want to make sure that users > don't end up paying for that and ISPs realize that the business is in the > added value services and applications. Is the only way IPv6 will succeed. > > But even if you don't agree with me about the cost issue, may be you agree > that the end-user don't need to justify why he needs more subnets and has > the right to keep his privacy. This is clearly part of ARIN authority. > > Same with avoiding the renumbering, otherwise, we are unfair defining policy > that avoid renumbering to LIRs, right ? > > > > >> Is also important that the user upgrading from a /64 or /56 to a /48 > >> don't need to renumber, so I will suggest that the ISP need to keep > >> reserved the complete /48. > >> > >> For those that believe that reserving the /48 is a space waste, I will > >> suggest to understand that this can be changed in the future (possible in > >> hundreds of years, in my opinion) if we really come into a situation where > >> we have to use the reserved space, even if that means renumbering some or > >> all the end-sites (I'm considering that most of the end-sites that will fall > >> into this situation will be residential customers). Renumbering once in > >> hundreds of years should not be considered as a trouble, as most probably, > >> residential users don't keep the same provider for so long time ... > >> > >> What I'm trying to avoid here is the situation that we have today which > >> users being forced to NAT and a single dynamic IPv4 address, which can turn > >> in a few years from now in something similar if you only get a /64 and need > >> /56 or /48. > > > > Do you think that a home network will need more than a million host > > addresses within "a few years from now"? I don't. > > Is not a question of how many addresses. It may be the case that we only use > a few addresses of each subnet. That's fine, is part of the design of IPv6 > that we accepted, which has lots of advantages, like the capability to run > auto-configuration, privacy, CGAs, and for sure more to come. > > > > > I do agree that home users may want to run more than one subnet, and may > > want more than one /64. Therefore I agree with the guideline that /64's > > should only be given out when it is known a priori that one and only one > > Which I will interpret as almost never a /64 should be given out (may be > only for a cellular phone and only if it is not connecting other devices > with other interfaces, otherwise is a mobile router). > > > subnet is needed, and that a /56 should be given out otherwise. However, > > I think that anyone who actually needs a /48 really should be considered a > > business customer, not a residential customer. > > As said, this is no longer the case if we look to the situation that can be > expected in a very few years. > > > > > -Scott > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Sat Apr 15 09:23:49 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 15 Apr 2006 09:23:49 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: On 04/14/06 at 11:41pm -0700, Owen DeLong wrote: > > > as we also discussed at the ARIN XVII meeting, it would be useful for > > some group to define guidelines for assignment policy that would clarify > > the issues you raise. it seems that in ARIN policy is not the correct > > place yet no other group comes to mind. anyway, as a rough suggestion, I > > would say that end sites should get 4 to 8 times as much address space > > assigned as they think they might use using today's networking techniques. > > > Perhaps we need a BCP track within ARIN for number resource utilization. > A process similar to, but, potentially a bit less formal than, the IRPEP > which would be used to develop "Recommended Practices for Number Resource > Allocation, Assignment, and Utilization". I like this idea. > I agree this doesn't belong in policy, but, I do think that ARIN might be > the right body to coalesce such information, at least on a regional basis. Perhaps we could use the existing policy process (or something similar and parallel) to develop recommendations, though. Have folks submit "Recommendation Proposals", which could be run through the PPML and presented at ARIN meetings. Perhaps a lower standard of consensus would be required for adoption... -Scott From jordi.palet at consulintel.es Sat Apr 15 10:25:46 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 15 Apr 2006 16:25:46 +0200 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <639B560272E2C6318C662821@imac-en0.delong.sj.ca.us> Message-ID: Hi Owen, See below. Regards, Jordi > De: Owen DeLong > Responder a: > Fecha: Fri, 14 Apr 2006 23:35:33 -0700 > Para: , "ppml at arin.net" > Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 > assignment and utilisation requirement - Last Call > > > > --On April 15, 2006 12:28:40 AM +0200 JORDI PALET MARTINEZ > wrote: > >> Hi Owen, >> >> Yes, I know, it may seem so, but is not the case. >> >> Actually for the ISP is cheaper to keep a flat infrastructure, having >> everything with /48. >> > I think that's variable from an infrastructure perspective, however, from > an RIR fees perspective, if each /32 costs $x, then, each /48 costs > either $x/65536 or $x/n where n is the number of customers you can > put into said /48. In the case where n>65536, the cost per /48 is > reduced. > >> I also don't think the RIR fees will make a difference, at least not in >> the short/medium term for that, but of course, this is something that is >> yet not clear. >> > Obviously at the moment when RIRs are waiving v6 fees, this is true. > However, given that a /32 costs $2,250/year and a /31 costs $4,500 > per year, if I can multiply the customer count in the first /32 > by as little as 2, it is useful. Yes, but following the same calculations, this means less than $0,035 per year per each /48 customer, so not a big deal, not an issue at all. I'm even happy to pay ten times that every month if needed, but I want to make sure that I don't need to explain to any ISP why I need a /48 instead of a /56 and have the chance to get that rejected or need to look for an alternative ISP just because this. > >> In theory the only reason for 2005-8 is to conserve space. If that's the >> case, then what I'm proposing will make it, as the reserved /48 which is >> not being used, will be available if we really reach the point where we >> used all the non-reserved space. A small policy modification at that >> point, will allow the ISPs to forget about those /48 reservations that >> have not been claimed by end-users. >> > With the possible exception of free address pool fragmentation, I would > agree with you to a certain extent. The only other problem I see is that > it won't be perceived as an issue until several ISPs have grabbed onto > multpile /32s with lots of empty reserved space and some other ISP(s) > need an unavailable /32. I agree this is a long way off, but, in terms > of IPv6 potential useful life, a long way off might not be far enough. Statistically seems to me highly improbable, because even in a situation of high level of addressing space utilization (which will never happen because we will have done a policy change before going into that situation), new ISPs will only happen if other close the business or similar situations. Anyway, is a complex situation to predict, and for sure we will not have the right crystal ball to look at and make a good guess ;-) > >> I think we should remember that if we agree to change the HD-ratio, the >> figures that Tony has calculated, and I think are realistic, give IPv6 a >> life of 480 years. Anyone still believe that IP (IPv4 or IPv6, doesn't >> matter for this case), will be still available in 200 years ? So ? >> > I've seen numbers (I think from Geoff Huston) that said it was more > like 60 years. I think Geoff figures were assuming that no change is done in the HD-ratio, right ? > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Sat Apr 15 10:31:13 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 15 Apr 2006 16:31:13 +0200 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: Message-ID: Hi Scott, No, that's a broken concept. We need to keep the IPv6 property of /64 for each subnet, in order to be able to use autoconfiguration, privacy, CGAs, etc. Regards, Jordi > De: Scott Leibrand > Responder a: > Fecha: Sat, 15 Apr 2006 09:14:44 -0400 (EDT) > Para: JORDI PALET MARTINEZ > CC: "ppml at arin.net" > Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 > assignment and utilisation requirement - Last Call > > A meta-question: > > If you end up needing more than 256 subnets for your house, and have a /56 > or even a /64, can you make your subnets /65's, /66's, etc? > > -Scott > > On 04/14/06 at 11:22pm +0200, JORDI PALET MARTINEZ > >> Hi Scott, >> >> See below, in-line. >> >> Regards, >> Jordi >> >> >> >> >>> De: Scott Leibrand >>> Responder a: >>> Fecha: Fri, 14 Apr 2006 16:35:25 -0400 (EDT) >>> Para: JORDI PALET MARTINEZ >>> CC: "ppml at arin.net" >>> Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 >>> assignment and utilisation requirement - Last Call >>> >>> On 04/14/06 at 10:23pm +0200, JORDI PALET MARTINEZ >>> >> >>>> Hi, >>>> >>>> While I don't agree with this proposal (I still believe a default /48 >>>> should >>>> be assigned to any end-site if is non-portable space), >>> >>> Why? Do you think that a site with 65,000 subnets can claim to just be a >>> non-business residential customer? >> >> Yes I know from current research of services and products that will be in >> the market in the next few years, that residential customers will need more >> than 256 subnets. >> >> I'm not so convinced about 65.000 subnets, but I'm given the choice in >> between 256 subnets or 65.000 subnets, I much prefer to be sure than became >> short. >> >> And I'm still talking about homes (smart homes if you want to say), so >> residential customers, not business customers. However, there is more and >> more people working from their home, may be you want to consider them a >> special case also ;-) >> >>> >>>> I would accept it, if the final text of the policy make sure that an >>>> end-site has the right to request to the LIR for being upgraded from the >>>> /64 or /56 to the /48 without the need for a detailed justification (as >>>> otherwise may go against the end-site right to privacy) and the end-site >>>> can get that upgrade at no extra recurrent costs (a setup fee is >>>> acceptable if it match real costs for that and a small recurrent cost >>>> which match the *real* cost for that space as paid to the RIR will be >>>> also acceptable). >>> >>> This sounds to me like something *way* outside of ARIN's authority. >> >> I'm not sure in the case of ARIN, but in other registries, the charging by >> LIRs to end-customers is expected to be to cover their administrative costs, >> not to make money out of the addresses and ASNs, which are a human property. >> >> On the other way around, the LIRs need to understand that charging for the >> addresses at the end is against their business. I've already talked about >> this in other occasions. In Spain you pay typically 12 Euros for each IPv4 >> address per month (while the cost of the ADSL line is now 20 Euros, >> including free national phone calls). Obviously the ISPs aren't making any >> *real* business, because almost none of the 4.5 million broadband users in >> the country pay for that. However, this makes almost impossible to the ISPs >> to deploy easily new services and applications which can be charged for and >> thus make much more profit than with the 12 Euros per address (not to say >> the extra cost of running NAT and providing support for the problems caused >> by NAT). >> >> Unfortunately, most of the ISPs, still don't see that and I doubt that in >> the short term they will see it. As said, I want to make sure that users >> don't end up paying for that and ISPs realize that the business is in the >> added value services and applications. Is the only way IPv6 will succeed. >> >> But even if you don't agree with me about the cost issue, may be you agree >> that the end-user don't need to justify why he needs more subnets and has >> the right to keep his privacy. This is clearly part of ARIN authority. >> >> Same with avoiding the renumbering, otherwise, we are unfair defining policy >> that avoid renumbering to LIRs, right ? >> >>> >>>> Is also important that the user upgrading from a /64 or /56 to a /48 >>>> don't need to renumber, so I will suggest that the ISP need to keep >>>> reserved the complete /48. >>>> >>>> For those that believe that reserving the /48 is a space waste, I will >>>> suggest to understand that this can be changed in the future (possible in >>>> hundreds of years, in my opinion) if we really come into a situation where >>>> we have to use the reserved space, even if that means renumbering some or >>>> all the end-sites (I'm considering that most of the end-sites that will >>>> fall >>>> into this situation will be residential customers). Renumbering once in >>>> hundreds of years should not be considered as a trouble, as most probably, >>>> residential users don't keep the same provider for so long time ... >>>> >>>> What I'm trying to avoid here is the situation that we have today which >>>> users being forced to NAT and a single dynamic IPv4 address, which can turn >>>> in a few years from now in something similar if you only get a /64 and need >>>> /56 or /48. >>> >>> Do you think that a home network will need more than a million host >>> addresses within "a few years from now"? I don't. >> >> Is not a question of how many addresses. It may be the case that we only use >> a few addresses of each subnet. That's fine, is part of the design of IPv6 >> that we accepted, which has lots of advantages, like the capability to run >> auto-configuration, privacy, CGAs, and for sure more to come. >> >>> >>> I do agree that home users may want to run more than one subnet, and may >>> want more than one /64. Therefore I agree with the guideline that /64's >>> should only be given out when it is known a priori that one and only one >> >> Which I will interpret as almost never a /64 should be given out (may be >> only for a cellular phone and only if it is not connecting other devices >> with other interfaces, otherwise is a mobile router). >> >>> subnet is needed, and that a /56 should be given out otherwise. However, >>> I think that anyone who actually needs a /48 really should be considered a >>> business customer, not a residential customer. >> >> As said, this is no longer the case if we look to the situation that can be >> expected in a very few years. >> >>> >>> -Scott >>> >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >> >> >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From lea.roberts at stanford.edu Sat Apr 15 10:43:28 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sat, 15 Apr 2006 07:43:28 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: Message-ID: Scott - the /64 boundary is hardwired in a lot of places and so that is contraindicated... the answer is under 2005-8 is that you should be able to easily get another /56 from your provider (or, if you're willing to renumber, you should be able to get a /52 once you've reached 60-100 subnet assignments in the /56). note that 2005-8 assumes you are playing under the PA rules. there's no reason a provider shouldn't have some address space (not necessarily continguous) available at the nearest aggregation point in their infrastructure. /Lea On Sat, 15 Apr 2006, Scott Leibrand wrote: > A meta-question: > > If you end up needing more than 256 subnets for your house, and have a /56 > or even a /64, can you make your subnets /65's, /66's, etc? > > -Scott > > On 04/14/06 at 11:22pm +0200, JORDI PALET MARTINEZ > > Hi Scott, > > > > See below, in-line. > > > > Regards, > > Jordi > > > > > > > > > > > De: Scott Leibrand > > > Responder a: > > > Fecha: Fri, 14 Apr 2006 16:35:25 -0400 (EDT) > > > Para: JORDI PALET MARTINEZ > > > CC: "ppml at arin.net" > > > Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 > > > assignment and utilisation requirement - Last Call > > > > > > On 04/14/06 at 10:23pm +0200, JORDI PALET MARTINEZ > > > > > > > >> Hi, > > >> > > >> While I don't agree with this proposal (I still believe a default /48 should > > >> be assigned to any end-site if is non-portable space), > > > > > > Why? Do you think that a site with 65,000 subnets can claim to just be a > > > non-business residential customer? > > > > Yes I know from current research of services and products that will be in > > the market in the next few years, that residential customers will need more > > than 256 subnets. > > > > I'm not so convinced about 65.000 subnets, but I'm given the choice in > > between 256 subnets or 65.000 subnets, I much prefer to be sure than became > > short. > > > > And I'm still talking about homes (smart homes if you want to say), so > > residential customers, not business customers. However, there is more and > > more people working from their home, may be you want to consider them a > > special case also ;-) > > > > > > > >> I would accept it, if the final text of the policy make sure that an > > >> end-site has the right to request to the LIR for being upgraded from the > > >> /64 or /56 to the /48 without the need for a detailed justification (as > > >> otherwise may go against the end-site right to privacy) and the end-site > > >> can get that upgrade at no extra recurrent costs (a setup fee is > > >> acceptable if it match real costs for that and a small recurrent cost > > >> which match the *real* cost for that space as paid to the RIR will be > > >> also acceptable). > > > > > > This sounds to me like something *way* outside of ARIN's authority. > > > > I'm not sure in the case of ARIN, but in other registries, the charging by > > LIRs to end-customers is expected to be to cover their administrative costs, > > not to make money out of the addresses and ASNs, which are a human property. > > > > On the other way around, the LIRs need to understand that charging for the > > addresses at the end is against their business. I've already talked about > > this in other occasions. In Spain you pay typically 12 Euros for each IPv4 > > address per month (while the cost of the ADSL line is now 20 Euros, > > including free national phone calls). Obviously the ISPs aren't making any > > *real* business, because almost none of the 4.5 million broadband users in > > the country pay for that. However, this makes almost impossible to the ISPs > > to deploy easily new services and applications which can be charged for and > > thus make much more profit than with the 12 Euros per address (not to say > > the extra cost of running NAT and providing support for the problems caused > > by NAT). > > > > Unfortunately, most of the ISPs, still don't see that and I doubt that in > > the short term they will see it. As said, I want to make sure that users > > don't end up paying for that and ISPs realize that the business is in the > > added value services and applications. Is the only way IPv6 will succeed. > > > > But even if you don't agree with me about the cost issue, may be you agree > > that the end-user don't need to justify why he needs more subnets and has > > the right to keep his privacy. This is clearly part of ARIN authority. > > > > Same with avoiding the renumbering, otherwise, we are unfair defining policy > > that avoid renumbering to LIRs, right ? > > > > > > > >> Is also important that the user upgrading from a /64 or /56 to a /48 > > >> don't need to renumber, so I will suggest that the ISP need to keep > > >> reserved the complete /48. > > >> > > >> For those that believe that reserving the /48 is a space waste, I will > > >> suggest to understand that this can be changed in the future (possible in > > >> hundreds of years, in my opinion) if we really come into a situation where > > >> we have to use the reserved space, even if that means renumbering some or > > >> all the end-sites (I'm considering that most of the end-sites that will fall > > >> into this situation will be residential customers). Renumbering once in > > >> hundreds of years should not be considered as a trouble, as most probably, > > >> residential users don't keep the same provider for so long time ... > > >> > > >> What I'm trying to avoid here is the situation that we have today which > > >> users being forced to NAT and a single dynamic IPv4 address, which can turn > > >> in a few years from now in something similar if you only get a /64 and need > > >> /56 or /48. > > > > > > Do you think that a home network will need more than a million host > > > addresses within "a few years from now"? I don't. > > > > Is not a question of how many addresses. It may be the case that we only use > > a few addresses of each subnet. That's fine, is part of the design of IPv6 > > that we accepted, which has lots of advantages, like the capability to run > > auto-configuration, privacy, CGAs, and for sure more to come. > > > > > > > > I do agree that home users may want to run more than one subnet, and may > > > want more than one /64. Therefore I agree with the guideline that /64's > > > should only be given out when it is known a priori that one and only one > > > > Which I will interpret as almost never a /64 should be given out (may be > > only for a cellular phone and only if it is not connecting other devices > > with other interfaces, otherwise is a mobile router). > > > > > subnet is needed, and that a /56 should be given out otherwise. However, > > > I think that anyone who actually needs a /48 really should be considered a > > > business customer, not a residential customer. > > > > As said, this is no longer the case if we look to the situation that can be > > expected in a very few years. > > > > > > > > -Scott > > > > > > > > > > > > > ********************************************** > > The IPv6 Portal: http://www.ipv6tf.org > > > > Barcelona 2005 Global IPv6 Summit > > Slides available at: > > http://www.ipv6-es.com > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Sat Apr 15 10:44:39 2006 From: randy at psg.com (Randy Bush) Date: Sat, 15 Apr 2006 04:44:39 -1000 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call References: Message-ID: <17473.1751.659052.317012@roam.psg.com> > the /64 boundary is hardwired in a lot of places and so that is > contraindicated. it was specified NOT to be hardwired. randy From tme at multicasttech.com Sat Apr 15 11:01:08 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 15 Apr 2006 11:01:08 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <444003A2.10005@arin.net> References: <444003A2.10005@arin.net> Message-ID: <093E87D2-5CC3-45EE-8C6A-C78756596716@multicasttech.com> I support 2005-1 as currently written. Regards Marshall Eubanks On Apr 14, 2006, at 4:18 PM, Member Services wrote: > The ARIN Advisory Council (AC), acting under the provisions of the > ARIN > Internet Resource Policy Evaluation Process (IRPEP), has reviewed > Policy > Proposal 2005-1: Provider-independent IPv6 Assignments for End > Sites and > has determined that there is community consensus in favor of the > proposal, as edited below, to move it to last call. The AC added the > final sentence to section 6.5.8.2. as shown below. The AC made this > determination at their meeting at the conclusion of the ARIN Public > Policy meeting on April 11, 2006. The results of the AC meeting were > reported by the Chair of the AC at the member meeting. This report can > be found at > http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html > > The policy proposal text is provided below and is also available at > http://www.arin.net/policy/proposals/2005_1.html > > Comments are encouraged. All comments should be provided to > ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, > April 28, 2006. > > 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) > > ###*### > > Policy Proposal 2005-1: Provider-independent IPv6 Assignments for > End Sites > > Policy statement: > > Add new subsection in section 6.5 of the NRPM: > > 6.5.8. Direct assignments to end sites > > 6.5.8.1. To qualify for a direct assignment, an organization must: > > a) not be an IPv6 LIR; and > b) Qualify for an IPv4 assignment or allocation from ARIN under the > IPv4 > policy currently in effect. > > 6.5.8.2. Direct assignment size to end sites > > Organizations that meet the direct end site assignment criteria are > eligible to receive a direct assignment. The minimum size of the > assignment is /48. > Organizations requesting a larger assignment must provide > documentation > justifying the need for additional subnets. > > These assignments shall be made from a distinctly identified prefix > and > shall be made with a reservation for growth of at least a /44. > > 6.5.8.3. Subsequent Assignment Size > > Additional assignments may be made when the need for additional > subnets > is justified. When possible assignments will be made from an adjacent > address block. > > Policy Rationale > > In IPv4 policy there are three main types of organizations that > addresses are delegated to. > > o ISP's receive allocations directly from ARIN or from other ISP's > o End Users receive assignments from ISP's > o Large and/or multihomed End Users receive assignments directly > from ARIN. > > The third category is currently missing from IPv6 policy and this is > believed to be severely hindering deployment by those > organizations. In > IPv6 policy-speak: > > o LIR's receive allocations directly from ARIN > o End Sites receive assignments from LIR's > > This policy proposes: > > o Large and/or multihomed End Sites receive assignments directly > from ARIN. > > This policy applies to organizations with networks that are large > and/or > multihomed. Like their IPv4 counterparts they do not make > assignments to > external organizations. They instead assign space internally to their > own facilities. Similarly to IPv4 These internal assignments are not > submitted to ARIN via swip/rwhois. > > For transition purposes an organization that qualifies for IPv4 space > today is considered eligible, regardless of whether they were > considered > an ISP or End User under IPv4 policy. It is expected that the IPv6 > only > (non transition) requirements will be developed as experience is > gained. > > It is recommended that these assignments be made from a separate > address > block set aside for this purpose and that at least a /44 be reserved > around each assignment for possible expansion. One bit should be > reserved around assignments /44 and larger. > > Timetable for implementation: immediately > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From jordi.palet at consulintel.es Sat Apr 15 11:27:01 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 15 Apr 2006 17:27:01 +0200 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <17473.1751.659052.317012@roam.psg.com> Message-ID: Hi Randy, My reading from the RFC4291 (IPv6 Addressing Architecture) regarding unicast addresses is based on: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." I'm curious about this, in case my interpretation is incorrect. Regards, Jordi > De: Randy Bush > Responder a: > Fecha: Sat, 15 Apr 2006 04:44:39 -1000 > Para: Lea Roberts > CC: "ppml at arin.net" > Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 > assignment and utilisation requirement - Last Call > >> the /64 boundary is hardwired in a lot of places and so that is >> contraindicated. > > it was specified NOT to be hardwired. > > randy > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From lea.roberts at stanford.edu Sat Apr 15 11:30:32 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sat, 15 Apr 2006 08:30:32 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <17473.1751.659052.317012@roam.psg.com> Message-ID: On Sat, 15 Apr 2006, Randy Bush wrote: > > the /64 boundary is hardwired in a lot of places and so that is > > contraindicated. > > it was specified NOT to be hardwired. I haven't tried it... I know in the discussions leading up to 2005-8, that there are alot of mechanisms, some previously specified by Jordi, that have been specified assuming the /64 boundary, so trying to move that would have had a high pain ratio. From james at towardex.com Sat Apr 15 12:54:29 2006 From: james at towardex.com (James Jun) Date: Sat, 15 Apr 2006 12:54:29 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6Assignments for End Sites - Last Call In-Reply-To: <093E87D2-5CC3-45EE-8C6A-C78756596716@multicasttech.com> Message-ID: <20060415165128.1211D6D446@mx01.bos.ma.towardex.com> I support 2005-1. james On Apr 14, 2006, at 4:18 PM, Member Services wrote: > > The ARIN Advisory Council (AC), acting under the provisions of the > > ARIN > > Internet Resource Policy Evaluation Process (IRPEP), has reviewed > > Policy > > Proposal 2005-1: Provider-independent IPv6 Assignments for End > > Sites and > > has determined that there is community consensus in favor of the > > proposal, as edited below, to move it to last call. The AC added the > > final sentence to section 6.5.8.2. as shown below. The AC made this > > determination at their meeting at the conclusion of the ARIN Public > > Policy meeting on April 11, 2006. The results of the AC meeting were > > reported by the Chair of the AC at the member meeting. This report can > > be found at > > http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html > > > > The policy proposal text is provided below and is also available at > > http://www.arin.net/policy/proposals/2005_1.html > > > > Comments are encouraged. All comments should be provided to > > ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, > > April 28, 2006. > > > > 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) > > > > ###*### > > > > Policy Proposal 2005-1: Provider-independent IPv6 Assignments for > > End Sites > > > > Policy statement: > > > > Add new subsection in section 6.5 of the NRPM: > > > > 6.5.8. Direct assignments to end sites > > > > 6.5.8.1. To qualify for a direct assignment, an organization must: > > > > a) not be an IPv6 LIR; and > > b) Qualify for an IPv4 assignment or allocation from ARIN under the > > IPv4 > > policy currently in effect. > > > > 6.5.8.2. Direct assignment size to end sites > > > > Organizations that meet the direct end site assignment criteria are > > eligible to receive a direct assignment. The minimum size of the > > assignment is /48. > > Organizations requesting a larger assignment must provide > > documentation > > justifying the need for additional subnets. > > > > These assignments shall be made from a distinctly identified prefix > > and > > shall be made with a reservation for growth of at least a /44. > > > > 6.5.8.3. Subsequent Assignment Size > > > > Additional assignments may be made when the need for additional > > subnets > > is justified. When possible assignments will be made from an adjacent > > address block. > > > > Policy Rationale > > > > In IPv4 policy there are three main types of organizations that > > addresses are delegated to. > > > > o ISP's receive allocations directly from ARIN or from other ISP's > > o End Users receive assignments from ISP's > > o Large and/or multihomed End Users receive assignments directly > > from ARIN. > > > > The third category is currently missing from IPv6 policy and this is > > believed to be severely hindering deployment by those > > organizations. In > > IPv6 policy-speak: > > > > o LIR's receive allocations directly from ARIN > > o End Sites receive assignments from LIR's > > > > This policy proposes: > > > > o Large and/or multihomed End Sites receive assignments directly > > from ARIN. > > > > This policy applies to organizations with networks that are large > > and/or > > multihomed. Like their IPv4 counterparts they do not make > > assignments to > > external organizations. They instead assign space internally to their > > own facilities. Similarly to IPv4 These internal assignments are not > > submitted to ARIN via swip/rwhois. > > > > For transition purposes an organization that qualifies for IPv4 space > > today is considered eligible, regardless of whether they were > > considered > > an ISP or End User under IPv4 policy. It is expected that the IPv6 > > only > > (non transition) requirements will be developed as experience is > > gained. > > > > It is recommended that these assignments be made from a separate > > address > > block set aside for this purpose and that at least a /44 be reserved > > around each assignment for possible expansion. One bit should be > > reserved around assignments /44 and larger. > > > > Timetable for implementation: immediately > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Sat Apr 15 15:48:09 2006 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Apr 2006 15:48:09 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: Not under the current RFCs. Owen --On April 15, 2006 9:14:44 AM -0400 Scott Leibrand wrote: > A meta-question: > > If you end up needing more than 256 subnets for your house, and have a /56 > or even a /64, can you make your subnets /65's, /66's, etc? > > -Scott > > On 04/14/06 at 11:22pm +0200, JORDI PALET MARTINEZ > >> Hi Scott, >> >> See below, in-line. >> >> Regards, >> Jordi >> >> >> >> >> > De: Scott Leibrand >> > Responder a: >> > Fecha: Fri, 14 Apr 2006 16:35:25 -0400 (EDT) >> > Para: JORDI PALET MARTINEZ >> > CC: "ppml at arin.net" >> > Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 >> > assignment and utilisation requirement - Last Call >> > >> > On 04/14/06 at 10:23pm +0200, JORDI PALET MARTINEZ >> > > > >> >> Hi, >> >> >> >> While I don't agree with this proposal (I still believe a default /48 >> >> should be assigned to any end-site if is non-portable space), >> > >> > Why? Do you think that a site with 65,000 subnets can claim to just >> > be a non-business residential customer? >> >> Yes I know from current research of services and products that will be in >> the market in the next few years, that residential customers will need >> more than 256 subnets. >> >> I'm not so convinced about 65.000 subnets, but I'm given the choice in >> between 256 subnets or 65.000 subnets, I much prefer to be sure than >> became short. >> >> And I'm still talking about homes (smart homes if you want to say), so >> residential customers, not business customers. However, there is more and >> more people working from their home, may be you want to consider them a >> special case also ;-) >> >> > >> >> I would accept it, if the final text of the policy make sure that an >> >> end-site has the right to request to the LIR for being upgraded from >> >> the /64 or /56 to the /48 without the need for a detailed >> >> justification (as otherwise may go against the end-site right to >> >> privacy) and the end-site can get that upgrade at no extra recurrent >> >> costs (a setup fee is acceptable if it match real costs for that and >> >> a small recurrent cost which match the *real* cost for that space as >> >> paid to the RIR will be also acceptable). >> > >> > This sounds to me like something *way* outside of ARIN's authority. >> >> I'm not sure in the case of ARIN, but in other registries, the charging >> by LIRs to end-customers is expected to be to cover their administrative >> costs, not to make money out of the addresses and ASNs, which are a >> human property. >> >> On the other way around, the LIRs need to understand that charging for >> the addresses at the end is against their business. I've already talked >> about this in other occasions. In Spain you pay typically 12 Euros for >> each IPv4 address per month (while the cost of the ADSL line is now 20 >> Euros, including free national phone calls). Obviously the ISPs aren't >> making any *real* business, because almost none of the 4.5 million >> broadband users in the country pay for that. However, this makes almost >> impossible to the ISPs to deploy easily new services and applications >> which can be charged for and thus make much more profit than with the 12 >> Euros per address (not to say the extra cost of running NAT and >> providing support for the problems caused by NAT). >> >> Unfortunately, most of the ISPs, still don't see that and I doubt that in >> the short term they will see it. As said, I want to make sure that users >> don't end up paying for that and ISPs realize that the business is in the >> added value services and applications. Is the only way IPv6 will succeed. >> >> But even if you don't agree with me about the cost issue, may be you >> agree that the end-user don't need to justify why he needs more subnets >> and has the right to keep his privacy. This is clearly part of ARIN >> authority. >> >> Same with avoiding the renumbering, otherwise, we are unfair defining >> policy that avoid renumbering to LIRs, right ? >> >> > >> >> Is also important that the user upgrading from a /64 or /56 to a /48 >> >> don't need to renumber, so I will suggest that the ISP need to keep >> >> reserved the complete /48. >> >> >> >> For those that believe that reserving the /48 is a space waste, I will >> >> suggest to understand that this can be changed in the future >> >> (possible in hundreds of years, in my opinion) if we really come into >> >> a situation where we have to use the reserved space, even if that >> >> means renumbering some or all the end-sites (I'm considering that >> >> most of the end-sites that will fall into this situation will be >> >> residential customers). Renumbering once in hundreds of years should >> >> not be considered as a trouble, as most probably, residential users >> >> don't keep the same provider for so long time ... >> >> >> >> What I'm trying to avoid here is the situation that we have today >> >> which users being forced to NAT and a single dynamic IPv4 address, >> >> which can turn in a few years from now in something similar if you >> >> only get a /64 and need /56 or /48. >> > >> > Do you think that a home network will need more than a million host >> > addresses within "a few years from now"? I don't. >> >> Is not a question of how many addresses. It may be the case that we only >> use a few addresses of each subnet. That's fine, is part of the design >> of IPv6 that we accepted, which has lots of advantages, like the >> capability to run auto-configuration, privacy, CGAs, and for sure more >> to come. >> >> > >> > I do agree that home users may want to run more than one subnet, and >> > may want more than one /64. Therefore I agree with the guideline that >> > /64's should only be given out when it is known a priori that one and >> > only one >> >> Which I will interpret as almost never a /64 should be given out (may be >> only for a cellular phone and only if it is not connecting other devices >> with other interfaces, otherwise is a mobile router). >> >> > subnet is needed, and that a /56 should be given out otherwise. >> > However, I think that anyone who actually needs a /48 really should be >> > considered a business customer, not a residential customer. >> >> As said, this is no longer the case if we look to the situation that can >> be expected in a very few years. >> >> > >> > -Scott >> > >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be >> aware that any disclosure, copying, distribution or use of the contents >> of this information, including attached files, is prohibited. >> >> >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Sat Apr 15 16:06:32 2006 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Apr 2006 16:06:32 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: <7813F247DB2F341086F291E7@odpwrbook.local> >> >> --On April 15, 2006 12:28:40 AM +0200 JORDI PALET MARTINEZ >> wrote: >> >>> Hi Owen, >>> >>> Yes, I know, it may seem so, but is not the case. >>> >>> Actually for the ISP is cheaper to keep a flat infrastructure, having >>> everything with /48. >>> >> I think that's variable from an infrastructure perspective, however, from >> an RIR fees perspective, if each /32 costs $x, then, each /48 costs >> either $x/65536 or $x/n where n is the number of customers you can >> put into said /48. In the case where n>65536, the cost per /48 is >> reduced. >> >>> I also don't think the RIR fees will make a difference, at least not in >>> the short/medium term for that, but of course, this is something that is >>> yet not clear. >>> >> Obviously at the moment when RIRs are waiving v6 fees, this is true. >> However, given that a /32 costs $2,250/year and a /31 costs $4,500 >> per year, if I can multiply the customer count in the first /32 >> by as little as 2, it is useful. > > Yes, but following the same calculations, this means less than $0,035 per > year per each /48 customer, so not a big deal, not an issue at all. I'm > even happy to pay ten times that every month if needed, but I want to > make sure that I don't need to explain to any ISP why I need a /48 > instead of a /56 and have the chance to get that rejected or need to look > for an alternative ISP just because this. > I agree that the justification process should be limited to "my intended topology requires it." up to a /48 per physical location (ignoring for the moment the ambiguities in the definition of physical location). However, as an example, in my house, I currently have 3 /24s which I am utilizing efficiently according to ARIN policy. I cannot envision at this time a requirement for more than a /56 and would not ask my ISP for more. (Frankly, a /60 would probably be plenty in my case). I know there's stuff on the horizon that is planning to use my refrigerator as gateway to the toaster network, coffee maker network, microwave network, and oven network, not to mention networks for the sink, the separate subnets for various controls in each bathroom, and, of course the lightswitch network. However, I just don't anticipate those needing to be on anything other than SLA, so, I still don't think I need more than a /56 from my ISP. In my neighborhood, I am one of the more high-tech oriented houses and I guarantee you the largest IP consumer in about a 1 mile radius (which includes a couple of schools). >> With the possible exception of free address pool fragmentation, I would >> agree with you to a certain extent. The only other problem I see is that >> it won't be perceived as an issue until several ISPs have grabbed onto >> multpile /32s with lots of empty reserved space and some other ISP(s) >> need an unavailable /32. I agree this is a long way off, but, in terms >> of IPv6 potential useful life, a long way off might not be far enough. > > Statistically seems to me highly improbable, because even in a situation > of high level of addressing space utilization (which will never happen > because we will have done a policy change before going into that > situation), new ISPs will only happen if other close the business or > similar situations. Anyway, is a complex situation to predict, and for > sure we will not have the right crystal ball to look at and make a good > guess ;-) > That simply isn't true. There are new ISPs in the US on a nearly daily basis. Many of them close their doors or are acquired in 1-2 years, but, they spring up constantly. Unfortunately, in the case of acquisition, either the acquiring organization will either acquire the address space as well (minimal disruption to customers and most likely scenario) or require some period of time to renumber customers out of the space (usually measured in multiple years in my experience). In either case, the churn in the industry alone is likely to result in address space fragmentation. >> >>> I think we should remember that if we agree to change the HD-ratio, the >>> figures that Tony has calculated, and I think are realistic, give IPv6 a >>> life of 480 years. Anyone still believe that IP (IPv4 or IPv6, doesn't >>> matter for this case), will be still available in 200 years ? So ? >>> >> I've seen numbers (I think from Geoff Huston) that said it was more >> like 60 years. > > I think Geoff figures were assuming that no change is done in the > HD-ratio, right ? > That wasn't my understanding, but, I could be wrong. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Sat Apr 15 16:10:06 2006 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Apr 2006 16:10:06 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: <484A15C0C988D328C2C800D7@odpwrbook.local> I believe it is not hardwired in the protocol, but, for any given subnet, there are a number of features that are not usable if the subnet does not conform to the /64 rule. I do not believe, for example, that point to point links are required to have a /64 dedicated to them. I believe the average provider could number all of their point to point links out of a single /64 broken into /124 or similar size chunks. Owen --On April 15, 2006 8:30:32 AM -0700 Lea Roberts wrote: > On Sat, 15 Apr 2006, Randy Bush wrote: > >> > the /64 boundary is hardwired in a lot of places and so that is >> > contraindicated. >> >> it was specified NOT to be hardwired. > > I haven't tried it... I know in the discussions leading up to 2005-8, > that there are a lot of mechanisms, some previously specified by Jordi, > that have been specified assuming the /64 boundary, so trying to move that > would have had a high pain ratio. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From randy at psg.com Sat Apr 15 16:45:25 2006 From: randy at psg.com (Randy Bush) Date: Sat, 15 Apr 2006 10:45:25 -1000 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call References: <17473.1751.659052.317012@roam.psg.com> Message-ID: <17473.23397.397299.365020@roam.psg.com> >>> the /64 boundary is hardwired in a lot of places and so that is >>> contraindicated. >> it was specified NOT to be hardwired. > I haven't tried it... I know in the discussions leading up to 2005-8, > that there are alot of mechanisms, some previously specified by Jordi uh, as much as i like jordi, he does not specify ip architecture > that have been specified assuming the /64 boundary, so trying to move that > would have had a high pain ratio. a - it is specifically NOT specified in architecture. architecture specifically says (or used to say) that it should not be a hard boundary in implementations. b - many of us use p2p links of /126 today randy From jordi.palet at consulintel.es Sat Apr 15 17:30:58 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 15 Apr 2006 23:30:58 +0200 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <17473.23397.397299.365020@roam.psg.com> Message-ID: Hi Randy, May be I'm reading "hardwired" in a different way/context. For me, in an end-user network (in this context a residential customer), the /64 must not be subnetted, if we want to keep things working automatically (privacy, autoconfiguration, etc.). If we want to get rid off supporting users problems with NAT, and then decide to start breaking things in IPv6 ... we are then loosing part of the advantages. I agree that in some context, such as point-to-point links, we can use /126, but I still believe is better to keep using /64 for those cases in order to ensure that some features also work there. Also, my understanding is that all the OS and router implementations that I've tried, will support a manual configuration of subnets ignoring the /64 boundary, but again, then automatic things don't work anymore. So may be "hardwired" is not correct (even may be is actually the case in sensors or small devices, embedded OSs, which will rely only in autoconfiguration because can't be manually configured), but the meaning/context used by Lea is still the same: Subnetting a /64 in local area networks is contraindicated and is against RFC4291 and must not be used as a way to extend the addressing space instead of allocating a bigger address block. Regards, Jordi > De: Randy Bush > Responder a: > Fecha: Sat, 15 Apr 2006 10:45:25 -1000 > Para: Lea Roberts > CC: "ppml at arin.net" > Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 > assignment and utilisation requirement - Last Call > >>>> the /64 boundary is hardwired in a lot of places and so that is >>>> contraindicated. >>> it was specified NOT to be hardwired. >> I haven't tried it... I know in the discussions leading up to 2005-8, >> that there are alot of mechanisms, some previously specified by Jordi > > uh, as much as i like jordi, he does not specify ip architecture > >> that have been specified assuming the /64 boundary, so trying to move that >> would have had a high pain ratio. > > a - it is specifically NOT specified in architecture. architecture > specifically says (or used to say) that it should not be a hard > boundary in implementations. > > b - many of us use p2p links of /126 today > > randy > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From lea.roberts at stanford.edu Sat Apr 15 17:42:14 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sat, 15 Apr 2006 14:42:14 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <17473.23397.397299.365020@roam.psg.com> Message-ID: Randy - On Sat, 15 Apr 2006, Randy Bush wrote: > >>> the /64 boundary is hardwired in a lot of places and so that is > >>> contraindicated. > >> it was specified NOT to be hardwired. > > I haven't tried it... I know in the discussions leading up to 2005-8, > > that there are alot of mechanisms, some previously specified by Jordi > > uh, as much as i like jordi, he does not specify ip architecture thanks for pointing out the errors of my poor word choices. I will certainly try to consider those choices more carefully in the future so as to not unintentionally convey inaccurate implications. > > that have been specified assuming the /64 boundary, so trying to move that > > would have had a high pain ratio. > > a - it is specifically NOT specified in architecture. architecture > specifically says (or used to say) that it should not be a hard > boundary in implementations. > > b - many of us use p2p links of /126 today I readily acknowledge it's possible if one is willing to do without those mechanisms which have enumerated elsewhere (thanks, Owen :-). I stand by my assertion that obtaining more address space should never be difficult or expensive, so that getting an additional or expanded assignment would be the normal way for dealing with the need for more subnets. one question for you, Randy: is 2005-8 at least moving in the correct direction for IPv6 address assignment policy or do you think the current RFC3177-based assignment policies should continue? thanks, /Lea From michel at arneill-py.sacramento.ca.us Sat Apr 15 18:49:20 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 15 Apr 2006 15:49:20 -0700 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call Message-ID: > Jordi wrote: > but the meaning/context used by Lea is still the same: Subnetting > a /64 in local area networks is contraindicated and is against > RFC4291 and must not be used as a way to extend the addressing > space instead of allocating a bigger address block. Indeed. Besides, it's dangerous and futile. Dangerous, because if someday someone invents an authentication mechanism with crypto embedded in the MAC address, it won't work. Something like VRPP that requires one or more phantom addresses would not work. Futile, because with all the billions of homes (1) using a /64 for 2 or 3 PCs, saving a few crumbs out of PTP links does not make much of a difference. I will point out that there is going to be enough of a schism between ARIN and the IETF over 2005-8 and 2005-1 already; just because a few disgruntled people did not have their way in the IETF means that ARIN can go over everything they have done. Michel. (1) In the future, of course. From randy at psg.com Sat Apr 15 19:51:07 2006 From: randy at psg.com (Randy Bush) Date: Sat, 15 Apr 2006 13:51:07 -1000 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call References: <17473.23397.397299.365020@roam.psg.com> Message-ID: <17473.34539.981555.932654@roam.psg.com> >>> that have been specified assuming the /64 boundary, so trying to move that >>> would have had a high pain ratio. >> a - it is specifically NOT specified in architecture. architecture >> specifically says (or used to say) that it should not be a hard >> boundary in implementations. >> b - many of us use p2p links of /126 today > I readily acknowledge it's possible if one is willing to do > without those mechanisms which have enumerated elsewhere i am specifically concerned that the /64 magic not be sprinkled places where it is not clearly required. > I stand by my assertion that obtaining more address space should > never be difficult or expensive, so that getting an additional or > expanded assignment would be the normal way for dealing with the > need for more subnets. orthogonal issue > is 2005-8 at least moving in the correct direction for IPv6 address > assignment policy or do you think the current RFC3177-based assignment > policies should continue? imiho, yes. but i find the /48, /56, /64 language to be too restrictive. they could be couched in 'recommend' as most other things in the proposal are. randy From lea.roberts at stanford.edu Sun Apr 16 01:48:45 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sat, 15 Apr 2006 22:48:45 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <17473.34539.981555.932654@roam.psg.com> Message-ID: > i am specifically concerned that the /64 magic not be sprinkled > places where it is not clearly required. OK - acknowledged. > > is 2005-8 at least moving in the correct direction for IPv6 address > > assignment policy or do you think the current RFC3177-based assignment > > policies should continue? > > imiho, yes. but i find the /48, /56, /64 language to be too > restrictive. they could be couched in 'recommend' as most other > things in the proposal are. so if the word "recommendations" replaced "guidelines", would it work better for you? i.e.: The following recommendations may be useful (but they are only recommendations): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites how do others feel? does anyone out there prefer "guidelines"?? :-) thanks for your input! /Lea From sleibrand at internap.com Sun Apr 16 02:02:36 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sun, 16 Apr 2006 02:02:36 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: On 04/15/06 at 10:48pm -0700, Lea Roberts wrote: > so if the word "recommendations" replaced "guidelines", would it work > better for you? i.e.: > > The following recommendations may be useful (but they are only > recommendations): > > - /64 when it is known that one and only one subnet is needed > > - /56 for small sites, those expected to need only a few subnets over > the next 5 years. > > - /48 for larger sites > > how do others feel? does anyone out there prefer "guidelines"?? :-) Either "recommendations" or "guidelines" is fine with me. Either one expresses clearly enough that ISPs should allocate as much space as might reasonably be needed, without imposing any undue restrictions on what exactly the ISPs must do in any given situation. -Scott From randy at psg.com Sun Apr 16 03:27:45 2006 From: randy at psg.com (Randy Bush) Date: Sat, 15 Apr 2006 21:27:45 -1000 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call References: <17473.34539.981555.932654@roam.psg.com> Message-ID: <17473.61937.962788.674981@roam.psg.com> > so if the word "recommendations" replaced "guidelines", would it work > better for you? i.e.: > The following recommendations may be useful (but they are only > recommendations): > - /64 when it is known that one and only one subnet is needed > - /56 for small sites, those expected to need only a few subnets over > the next 5 years. > - /48 for larger sites very much randy From christopher.morrow at gmail.com Sun Apr 16 12:00:31 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sun, 16 Apr 2006 12:00:31 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <17473.61937.962788.674981@roam.psg.com> References: <17473.34539.981555.932654@roam.psg.com> <17473.61937.962788.674981@roam.psg.com> Message-ID: <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> On 4/16/06, Randy Bush wrote: > > so if the word "recommendations" replaced "guidelines", would it work > > better for you? i.e.: > > The following recommendations may be useful (but they are only > > recommendations): > > - /64 when it is known that one and only one subnet is needed > > - /56 for small sites, those expected to need only a few subnets over > > the next 5 years. > > - /48 for larger sites > > very much I agree, I'd like to see a move away from the 'classful' ipv6 and to something more reasonable. 'recommendations' seems like a start. thanks! From jeroen at unfix.org Sun Apr 16 12:49:03 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 16 Apr 2006 18:49:03 +0200 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> Message-ID: <1145206143.23746.32.camel@firenze.zurich.ibm.com> [very nice cross posting going on here ;) ] On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote: [... large snip about trying to bash shim6 which is not finalized yet, thus how can you bash it ? Note: extra sarcasm included in this post. Eat the eggs with salt. ...] > Oh, and one thing I should have said last time: Technical arguments > are important, but they are only part of the decision process. In other words: "You are right with your arguments, but I just threw your args away as they are futile based on the comparison of money earned this way or the other."... > People (like me) have explained that the Internet is a business, and > in addition to being .. technically unsavory to many people, shim6 is > simply not viable in a business setting. And as you will only care for your business for the coming 10 or maybe 20 years you really can't care what happens to the internet afterward. The idea of IPv6 is (still not was) to have it around for quite some time longer than the lifespan of IPv4. Fortunately, the PI thing is far from the end of the world and will only help catch on, see below. Of course any vendor will love the idea of having to do another IP version of course, bring in the cash ;) > Neither backbone operators > (vendors) nor end users (customers) are warming to the idea. Just > the opposite. (At least in general, the one-in-a-million end user > with DSL and cable who likes the idea 'cause he can't figure out how > to spell "B-G-P" or doesn't want to pay for it is irrelevant.) Irrelevant for you as they don't give you money. Indeed, you only look at your own business interrest (and who can blame you for that ;) (Once though the internet was there for the masses and not only for the ones with cash) > So how do you get a technology widely accepted when the majority of > people involved do not think it is the best technical solution? When > the majority of vendors supposed to implement it will not do so for > technical -and- business reasons. There is for you indeed a business reason to not like it: the end-site won't have any reason to stick to the upstream. Which is indeed a bad business for many of the 'vendors' you mean. As Eliot Lear also said very clearly: Thanks for lining the vendors and all the stockholders pockets ;) That is in the long run, most likely in the coming 10-20 years the IPv6 routing tables will not have 'exploded' yet, but the folks selling equipment and having stocks of those venders after that most likely will have a nice retirement fund. Thanks to you! Nevertheless, the PI thing is really *not* a bad thing, as it can be used as an identifier for shim6, which is actually perfect. It just saves on having to do a complete policy process for getting address space for this type of usage. But thanks to this, this won't be needed and thus in the end anybody who can get PI can use a shim6-alike solution and won't have any problem with the upstream that actually wanted to lock them in by letting them pay loads for an entry in the BGP tables. Thus people voting for PI, thanks for helping shim6 or another solution in that space, progress a lot :) And finally on a much brighter note, especially for the shim6 folks: I know of quite a number of endsites that don't want to use BGP, the don't care about an entry in the routing tables, but do want to be multihomed in an easy way and also want to have 1 unique address space on their local network, but do want to use different upstreams. Shim6 will be perfect for this and thanks to the PI space their is the perfect identifier. Greets, Jeroen (being sarcastic, I guess the amounts of chocolate did it, but hey, I have a great excuse being only 7 mins away from the Lindt&Sprungli factory outlet, happy easter! ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From woody at pch.net Sun Apr 16 16:11:37 2006 From: woody at pch.net (Bill Woodcock) Date: Sun, 16 Apr 2006 13:11:37 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> References: <17473.34539.981555.932654@roam.psg.com> <17473.61937.962788.674981@roam.psg.com> <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> Message-ID: On Sun, 16 Apr 2006, Christopher Morrow wrote: > I'd like to see a move away from the 'classful' ipv6 and to > something more reasonable. 'recommendations' seems like a start. For the sake of PPML vote-counting, me too. -Bill From vaf at cisco.com Sun Apr 16 23:19:41 2006 From: vaf at cisco.com (Vince Fuller) Date: Sun, 16 Apr 2006 20:19:41 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <444003A2.10005@arin.net> References: <444003A2.10005@arin.net> Message-ID: <20060417031941.GA28204@vaf-lnx1.cisco.com> IMHO, this policy is a mistake. Quoting from the policy proposal: > This policy proposes: > > o Large and/or multihomed End Sites receive assignments directly from ARIN. > > This policy applies to organizations with networks that are large and/or > multihomed. Like their IPv4 counterparts they do not make assignments to > external organizations. They instead assign space internally to their > own facilities. Similarly to IPv4 These internal assignments are not > submitted to ARIN via swip/rwhois. It is precisely the "large and/or multihomed End Sites" that are driving growth of IPv4 routing state to be super-linear. Adopting this policy is a giant step toward non-scalable routing by the creation of an ipv6 routing "swamp" that will make the IPv4 global routing situation seem positively arid by comparison. Implementing this policy in the hopes that it will spur adoption of ipv6 smacks of the "tail wagging the dog", of doing *something* rather than the *right* thing so that "progress" can be demonstrated. Such an illusion of progress will only alleviate pressure to fix the real flaws in ipv6 (i.e. co-mingling of the endpoint identifier and routing locator in a single "address" field) that render it incompatible with the goal of a scalable routing system. Keep in mind that exponential and quadratic growth curves ramp-up very slowly when initially dealing with small numbers. I fear that by the time the consequences of this policy decision are felt, by the time the ipv6 routing state growth curves are observed to be super-linear, it will be difficult or impossible to deploy a something to handle that growth. Few people realize or remember how close the Internet routing system came to collapse during the pre-CIDR days... --Vince From randy at psg.com Mon Apr 17 01:06:06 2006 From: randy at psg.com (Randy Bush) Date: Sun, 16 Apr 2006 19:06:06 -1000 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> Message-ID: <17475.8766.762795.789527@roam.psg.com> > Few people realize or remember how close the Internet routing > system came to collapse during the pre-CIDR days... i don't think sean thought it was merely close. large portions of the net were in *serious* failure modes. santayana tells us that, as the majority of the folk discussing this are sufficiently new that they can not remember history, that they will doom us all to repeat it. but i take some cheer when you point out that > exponential and quadratic growth curves ramp-up very slowly when > initially dealing with small numbers. maybe i will have retired by the time these chickens come home to roost. randy From christopher.morrow at gmail.com Mon Apr 17 01:10:19 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 17 Apr 2006 01:10:19 -0400 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <1145206143.23746.32.camel@firenze.zurich.ibm.com> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> Message-ID: <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> (snip, snip,snip the cross-posting. and gmail did some crazy quoting :( ) On 4/16/06, Jeroen Massar wrote: > [very nice cross posting going on here ;) ] > > On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote: > In other words: "You are right with your arguments, but I just threw > your args away as they are futile based on the comparison of money > earned this way or the other."... > > > People (like me) have explained that the Internet is a business, and > > in addition to being .. technically unsavory to many people, shim6 is > > simply not viable in a business setting. > > And as you will only care for your business for the coming 10 or maybe > 20 years you really can't care what happens to the internet afterward. > I think patrick, while working for an evil capitalist company true, still does care what happens to the routing table after he stops caring about money... He's been around for quite some time and is a smart fellow. Things like shim6 and PI in v6 are very hard sells to operators of the networks that make up the Internet today. There is a reason for this, which Patrick outlined... ignoring that seems silly. > The idea of IPv6 is (still not was) to have it around for quite some > time longer than the lifespan of IPv4. Fortunately, the PI thing is far > from the end of the world and will only help catch on, see below stopping the PI train is hardly a simple matter. I agree that failing some reasonable 'multihoming' solution in v6, v6 is dead on arrival. I don't see that PI space is a smart move for the long term though :( If PI space gets final approval it will mean that all of the DFZ providers will have to carry all (or nearly all) /48 routes for eternity... There is no way to get back the /48's assigned under PI space after a multihoming solution that makes sense arrives, and there is, honestly, no driver to continue working on a multihoming solution now that there is PI space. Perhaps the original architects of v6 thought that by not proposing a multihoming solution, multihoming wouldn't happen? or that someone would arrive at a better solution than smaller deaggregates? Who knows... > > Of course any vendor will love the idea of having to do another IP > version of course, bring in the cash ;) because ipv6 was so profitable for them so far? most don't even do v6 correctly today, after 10 years of development! We are in a very bad position on all fronts here, shim6 isn't making it better, PI v6 isn't making it better and vendor's doing half-baked product deployments aren't either. it seems that backing up, restarting the 'new protocol' process is likely to end up with another 10 years wasted, so it's very hard to see a reasonable path forward at this time. > > > Neither backbone operators > > (vendors) nor end users (customers) are warming to the idea. Just > > the opposite. (At least in general, the one-in-a-million end user > > with DSL and cable who likes the idea 'cause he can't figure out how > > to spell "B-G-P" or doesn't want to pay for it is irrelevant.) > > Irrelevant for you as they don't give you money. Indeed, you only look I doubt patrick cares so much about whom they give money to... I think the real issues is if the network will survive in it's current state with more routes added to it? > > So how do you get a technology widely accepted when the majority of > > people involved do not think it is the best technical solution? When > > the majority of vendors supposed to implement it will not do so for > > technical -and- business reasons. > > There is for you indeed a business reason to not like it: the end-site > won't have any reason to stick to the upstream. Which is indeed a bad > business for many of the 'vendors' you mean. actually, take this up with the original designers/architects of v6... the decisions made then are why we are here today. :( vendors are evil, mostly, but they aren't fully to blame for this plight. > That is in the long run, most likely in the coming 10-20 years the IPv6 > routing tables will not have 'exploded' yet, but the folks selling you have some basis for this? I don't have that same faith... I think that quite quickly every entity that has ipv4 space will have ipv6 space in some PI fashion (if they have ipv4 PI space) and we'll all be stuck routing that and more from now until eternity. That will effectively double the current route table, which on much of the deployed networks isn't such a good plan. From christopher.morrow at gmail.com Mon Apr 17 01:11:08 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 17 Apr 2006 01:11:08 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: <17473.34539.981555.932654@roam.psg.com> <17473.61937.962788.674981@roam.psg.com> <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> Message-ID: <75cb24520604162211w3151092am85c52fc8e60fd3e9@mail.gmail.com> On 4/16/06, Bill Woodcock wrote: > On Sun, 16 Apr 2006, Christopher Morrow wrote: > > I'd like to see a move away from the 'classful' ipv6 and to > > something more reasonable. 'recommendations' seems like a start. > > For the sake of PPML vote-counting, me too. which part? no more classful-v6? or 'change to recommendations' ? From christopher.morrow at gmail.com Mon Apr 17 01:13:43 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 17 Apr 2006 01:13:43 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <20060417031941.GA28204@vaf-lnx1.cisco.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> Message-ID: <75cb24520604162213m60e68ab7o3122d27db6fc81c6@mail.gmail.com> On 4/16/06, Vince Fuller wrote: > IMHO, this policy is a mistake. > count this as a vote 'against' this policy proposal please. Thanks. From woody at pch.net Mon Apr 17 02:24:16 2006 From: woody at pch.net (Bill Woodcock) Date: Sun, 16 Apr 2006 23:24:16 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <75cb24520604162211w3151092am85c52fc8e60fd3e9@mail.gmail.com> References: <17473.34539.981555.932654@roam.psg.com> <17473.61937.962788.674981@roam.psg.com> <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> <75cb24520604162211w3151092am85c52fc8e60fd3e9@mail.gmail.com> Message-ID: > which part? no more classful-v6? or 'change to recommendations' ? Both. Classfulness is for the innumerate. And I'd prefer that innumerate people limit the extent of their influence over my behavior to recommendations, rather than requirements. -Bill From kloch at hotnic.net Mon Apr 17 02:31:48 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 17 Apr 2006 02:31:48 -0400 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> Message-ID: <44433654.9060004@hotnic.net> Christopher Morrow wrote: > you have some basis for this? I don't have that same faith... I think > that quite quickly every entity that has ipv4 space will have ipv6 > space in some PI fashion (if they have ipv4 PI space) and we'll all be > stuck routing that and more from now until eternity. That will > effectively double the current route table, which on much of the > deployed networks isn't such a good plan. While you make a good point about routes being around forever, I don't think it will double route tables. data from cidr-report.org: Current prefix/AS ratio in IPv4: 8.4:1 Current prefix/AS ratio in IPv6: 1.2:1 If every AS participating in IPv4 (22,000) also participated in IPv6 we might expect something closer to 27,000 v6 routes instead of 182,000. Why is the ratio so high in IPv4? If I'm reading the report properly about 4.2 prefixes/AS are due to deaggregation and the remaining 4.2 are due to "slow start" assignment policies. The generous minimums and reserved bits in v6 should eliminate the "slow start" factor. Separating PI space from ISP space in the beginning can help reduce the deaggregation factor if people filter out /48's by assignment range. That is highly recommended as there are at least 65,000 /48's in each ISP allocation. - Kevin From heldal at eml.cc Mon Apr 17 04:35:12 2006 From: heldal at eml.cc (Per Heldal) Date: Mon, 17 Apr 2006 10:35:12 +0200 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> Message-ID: <1145262912.315.259221292@webmail.messagingengine.com> On Mon, 17 Apr 2006 01:10:19 -0400, "Christopher Morrow" said: > stopping the PI train is hardly a simple matter. I agree that failing > some reasonable 'multihoming' solution in v6, v6 is dead on arrival. Maybe the community first has to agree on wether v6 really is ready for the mainstream? The majority in favor of a policy-change seem to indicate that people think it is. If not, we should be happy to wait for a proper technical solution and be happy with the existing policy. For years many of us have argued against using v6 without a scalable routing solution except possibly as a last resort when we actually do run out of v4 addresses. If we give in to the mounting pressure from governments (GOSIP anyone;) and various special-interest-groups *now* then PI is the only option. > I > don't see that PI space is a smart move for the long term though :( If > PI space gets final approval it will mean that all of the DFZ > providers will have to carry all (or nearly all) /48 routes for > eternity... There is no way to get back the /48's assigned under PI > space after a multihoming solution that makes sense arrives, Many seem to disagree. PI assignments could be made temporary, as suggested and discussed on the global-v6-list (http://www.apnic.net/mailing-lists/global-v6/index.shtml) > and there > is, honestly, no driver to continue working on a multihoming solution > now that there is PI space. The vast majority of the SMB-market does not qualify for PI. There are still plenty of drivers for alternatives. //per -- Per Heldal http://heldal.eml.cc/ From packetgrrl at gmail.com Mon Apr 17 08:59:35 2006 From: packetgrrl at gmail.com (cja@daydream.com) Date: Mon, 17 Apr 2006 06:59:35 -0600 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <20060417031941.GA28204@vaf-lnx1.cisco.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> Message-ID: Thanks for sending this Vince. I too remember those days when things were melting down. I often feel that no one else remembers. It is hard to watch the same mistakes being made over and over again. ---Cathy On 4/16/06, Vince Fuller wrote: > IMHO, this policy is a mistake. > > Quoting from the policy proposal: > > > This policy proposes: > > > > o Large and/or multihomed End Sites receive assignments directly from ARIN. > > > > This policy applies to organizations with networks that are large and/or > > multihomed. Like their IPv4 counterparts they do not make assignments to > > external organizations. They instead assign space internally to their > > own facilities. Similarly to IPv4 These internal assignments are not > > submitted to ARIN via swip/rwhois. > > It is precisely the "large and/or multihomed End Sites" that are driving > growth of IPv4 routing state to be super-linear. Adopting this policy is > a giant step toward non-scalable routing by the creation of an ipv6 routing > "swamp" that will make the IPv4 global routing situation seem positively > arid by comparison. > > Implementing this policy in the hopes that it will spur adoption of ipv6 > smacks of the "tail wagging the dog", of doing *something* rather than the > *right* thing so that "progress" can be demonstrated. Such an illusion of > progress will only alleviate pressure to fix the real flaws in ipv6 (i.e. > co-mingling of the endpoint identifier and routing locator in a single > "address" field) that render it incompatible with the goal of a scalable > routing system. > > Keep in mind that exponential and quadratic growth curves ramp-up very > slowly when initially dealing with small numbers. I fear that by the time > the consequences of this policy decision are felt, by the time the ipv6 > routing state growth curves are observed to be super-linear, it will be > difficult or impossible to deploy a something to handle that growth. Few > people realize or remember how close the Internet routing system came to > collapse during the pre-CIDR days... > > --Vince > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From ppml at rs.seastrom.com Mon Apr 17 09:26:58 2006 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Mon, 17 Apr 2006 09:26:58 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <20060417031941.GA28204@vaf-lnx1.cisco.com> (Vince Fuller's message of "Sun, 16 Apr 2006 20:19:41 -0700") References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> Message-ID: <878xq4l4d9.fsf@valhalla.seastrom.com> Vince Fuller writes: > Implementing this policy in the hopes that it will spur adoption of ipv6 > smacks of the "tail wagging the dog", of doing *something* rather than the > *right* thing so that "progress" can be demonstrated. Such an illusion of > progress will only alleviate pressure to fix the real flaws in ipv6 (i.e. > co-mingling of the endpoint identifier and routing locator in a single > "address" field) that render it incompatible with the goal of a scalable > routing system. Quite the opposite, actually. Ten years of feckless work on the routing problem by the IETF has yielded zilch. Perhaps the specter of routing table growth caused by actual adaptation of v6 will break the logjam. Then again, maybe it will take a crisis like it did last time (CIDR) but the risk (or certainty if we're successful) of a crisis in the future is not an excuse for not moving forward. Thomas Paine said "Lead, follow, or get out of the way". By the way, speaking of "illusion of progress", every time I see a presentation on a paper solution with no reference implementation (shim6 anyone?), I have OSI-era flashbacks. It's frankly embarrassing. How about a REAL solution from the IETF with a concentration on the "working code" part of "rough consensus and working code" so that we can get on with *repealing* 2005-1 after it's no longer necessary? ---Rob From Ed.Lewis at neustar.biz Mon Apr 17 09:40:19 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 17 Apr 2006 09:40:19 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> References: <17473.34539.981555.932654@roam.psg.com> <17473.61937.962788.674981@roam.psg.com> <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> Message-ID: At 12:00 -0400 4/16/06, Christopher Morrow wrote: >On 4/16/06, Randy Bush wrote: >> > so if the word "recommendations" replaced "guidelines", would it work >> > better for you? i.e.: >> > The following recommendations may be useful (but they are only >> > recommendations): >> > - /64 when it is known that one and only one subnet is needed >> > - /56 for small sites, those expected to need only a few subnets over >> > the next 5 years. >> > - /48 for larger sites >> >> very much > >I agree, I'd like to see a move away from the 'classful' ipv6 and to >something more reasonable. 'recommendations' seems like a start. >thanks! I was all for 2005-8 (http://www.arin.net/policy/proposals/2005_8.html) until I heard comments from Izumi Okutani (JPNIC) and the mic during the discussion following the presentation on April 10. The point was that there is an operation benefit observed in Japan from having boundaries. The benefit is, of course, not apparent when one looks at the architectural design of the protocol nor writing code that make use of it. The benefit is in the business models. E.g., if ISP A is dealing /52's and ISP B is dealing /56's, what happens when ISP B buys up ISP A? How do you merge customers used to having /52's into a billing model that is based on /56's? My take, which is not what she was suggesting, is that as a consumer who has a choice between DSL and cable modem, if I want to walk from one to the other, it would be beneficial to me if both were marketing the same prefix length. I won't say that this point is a show stopper, nor is it a compelling reason to move away from 'classless' networking, but when I heard the comment I stopped intending to vote for recommending 2005-8, (I didn't vote against it either) until I was clearer on this. I think that having set classes of size has a benefit, although not to the protocol. I don't think the RIRs are in the business of setting the classes, nor are the RIRs "better business bureaus" for the ISPs. I suppose that I agree with (I think it's Randy's) "very much" above. The "classes" ought to remain in print, but make it clear that these are what the membership senses are the right sizes. The policy does need to be clear on what ARIN uses as a measure of utilization. Looking at the URL above, it seems like the policy does do this - with the change of guidelines to recommendations. So I guess I am for the policy so long as the recommendations stay documented. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From weiler at tislabs.com Mon Apr 17 11:35:34 2006 From: weiler at tislabs.com (Sam Weiler) Date: Mon, 17 Apr 2006 11:35:34 -0400 (EDT) Subject: [ppml] Mutating RSA? Message-ID: I just noticed that the current registration services agreement (version 9, 4/7/06) includes text which appears to allow ARIN to modify the RSA at any time and without notice. This mutability seems unreasonablity biased in favor of ARIN. >From the 3rd paragraph, downcased for readability: "...ARIN reserves the right to modify this agreement at any time, with or without notice to Applicant. Changes will be effective after being posted on ARIN's website for 30 days, and will be applied to all applicants or persons receiving services. Continued receipt or use of the services constitues Applicant's acceptance of the changes. ..." Does anyone else find this objectionable? -- Sam From Ed.Lewis at neustar.biz Mon Apr 17 11:53:57 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 17 Apr 2006 11:53:57 -0400 Subject: [ppml] Mutating RSA? In-Reply-To: References: Message-ID: At 11:35 -0400 4/17/06, Sam Weiler wrote: >Does anyone else find this objectionable? The only part I find "objectionable" is: "APPLICANT SHOULD MONITOR ARIN'S WEBSITE TO REVIEW ANY CHANGES AFFECTING THIS AGREEMENT". (I'm too lazy to down case.) I would prefer (secure) e-mail, or better yet as this is an agreement, postal-mail to the designated member representative. (I assume RSA's are signed only with entities that have a DMR.) It is quite impractical to monitor a large web site for something that will probably happen rarely. As far as giving ARIN change control, ARIN is run by the membership, not the staff. If a harmful change was attempted, I'm sure it would be rectified accordingly. (But, the attempted change has to be made known.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From andrew.dul at quark.net Mon Apr 17 12:08:40 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Mon, 17 Apr 2006 16:08:40 +0000 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last C Message-ID: <20060417160840.9878.qmail@hoster908.com> > Yes I know from current research of services and products that will be in > the market in the next few years, that residential customers will need more > than 256 subnets. > > I'm not so convinced about 65.000 subnets, but I'm given the choice in > between 256 subnets or 65.000 subnets, I much prefer to be sure than became > short. Would you mind sharing your sources of information predicting the usage of more than 256 subnets in a normal residential environment. Thanks, Andrew From woody at pch.net Mon Apr 17 12:18:43 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 17 Apr 2006 09:18:43 -0700 (PDT) Subject: [ppml] Mutating RSA? In-Reply-To: References: Message-ID: On Mon, 17 Apr 2006, Sam Weiler wrote: > "...ARIN reserves the right to modify this agreement at any time, with > or without notice to Applicant. Changes will be effective after being > posted on ARIN's website for 30 days, and will be applied to all > applicants or persons receiving services. Continued receipt or use of > the services constitues Applicant's acceptance of the changes. ..." > > Does anyone else find this objectionable? Yup, that seems completely beyond the pale to me. -Bill From woody at pch.net Mon Apr 17 12:20:32 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 17 Apr 2006 09:20:32 -0700 (PDT) Subject: [ppml] Mutating RSA? In-Reply-To: References: Message-ID: On Mon, 17 Apr 2006, Edward Lewis wrote: > As far as giving ARIN change control, ARIN is run by the membership, > not the staff. I think you'd be hard pressed to attribute _that_ change to the membership. And it certainly didn't come from the AC or the Board. -Bill From Ed.Lewis at neustar.biz Mon Apr 17 12:33:16 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 17 Apr 2006 12:33:16 -0400 Subject: [ppml] Mutating RSA? In-Reply-To: References: Message-ID: At 9:20 -0700 4/17/06, Bill Woodcock wrote: > On Mon, 17 Apr 2006, Edward Lewis wrote: > > As far as giving ARIN change control, ARIN is run by the membership, > > not the staff. > >I think you'd be hard pressed to attribute _that_ change to the >membership. And it certainly didn't come from the AC or the Board. Perhaps I am being naive, having not poured over the RSA, but I assume that it, like everything else done by ARIN, ultimately answers to the membership. Whether via the AC or the BoT (whom we elect), or by our collective financial support. (I'm thinking of a discussion in which the BoT was free to suspend a policy that was wrecking undo havoc on the routing tables, as if there was a rush for PI v6 space. It seemed to me that the BoT was the ultimate arbiter of ARIN's actions.) The RSA is based on a body of legal work which is not in my area of experience. I don't have the time to study it and still work on what I am trained to do, therefore I trust that this work is otherwise properly reviewed. I am not looking to have to do this review, I don't anticipate any problems, so I don't think I can pull in any company lawyers for this. If it is up to people like me to review it, then I should ask - how does the membership make comments on the RSA, how does the membership influence it? Is there a means to appeal a change to the RSA? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From vaf at cisco.com Mon Apr 17 12:31:34 2006 From: vaf at cisco.com (Vince Fuller) Date: Mon, 17 Apr 2006 09:31:34 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <878xq4l4d9.fsf@valhalla.seastrom.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <878xq4l4d9.fsf@valhalla.seastrom.com> Message-ID: <20060417163134.GA10419@vaf-lnx1.cisco.com> > > Implementing this policy in the hopes that it will spur adoption of ipv6 > > smacks of the "tail wagging the dog", of doing *something* rather than the > > *right* thing so that "progress" can be demonstrated. Such an illusion of > > progress will only alleviate pressure to fix the real flaws in ipv6 (i.e. > > co-mingling of the endpoint identifier and routing locator in a single > > "address" field) that render it incompatible with the goal of a scalable > > routing system. > > Quite the opposite, actually. Ten years of feckless work on the > routing problem by the IETF has yielded zilch. Perhaps the specter of > routing table growth caused by actual adaptation of v6 will break the > logjam. Then again, maybe it will take a crisis like it did last time > (CIDR) but the risk (or certainty if we're successful) of a crisis in > the future is not an excuse for not moving forward. Thomas Paine said > "Lead, follow, or get out of the way". > > By the way, speaking of "illusion of progress", every time I see a > presentation on a paper solution with no reference implementation > (shim6 anyone?), I have OSI-era flashbacks. It's frankly > embarrassing. The IETF process failed ten+ years ago when a "solution" was picked that had been clearly shown to be inadquate at solving the known, hard problems. Since then, politics have triumphed over technology and all efforts to design a real solution have been effectively surpressed in the name of consensus-building around ipv6. There are some people, far brighter than me, who continue to try to fight the good fight, but the entrenched interests around ipv6 make that difficult-to-hopeless. (OK, now I'm sure I appear to be a conspiracy theorist, so this will be my last posting on this topic) Without a clear message from the IETF contituency that ipv6 is fundamentally flawed to the point of not being worth the time, effort, and expense of deployment, there is exactly "zilch" chance that the established path will be altered. "Moving forward" down a path that inexorably leads to a crisis vindicates those that deny the existance of a problem (think global warming here) while the existance of the problem is masked by the early, shallow slope of the growth curve. > How about a REAL solution from the IETF with a concentration on the > "working code" part of "rough consensus and working code" so that we > can get on with *repealing* 2005-1 after it's no longer necessary? Without a commitment to the creation of a solution that obviates 2005-1, this is a mistake. If there is one thing we've learned from the development and deployment of CIDR, "temporary" solutions aren't, especially when there is no clear direction to the "permanent" solution or even a clear definition of the problem to be solved. The Internet faces pressure for change today: the exhaution of the 32-bit IP address space. Spending billions of dollars to deploy a band-aid that will only trade this crisis for another one a few years down the road hardly seems like a wise investment, especially when one considers that the installed base, and thus the cost to deploy a fork-lift "upgrade", will be orders of magnitude bigger in the future. Fix ipv6 now and you inconvenience a few early adopters who have to roll-out new implementations; fix it later (assuming there is a wide-scale deployment and transition from IPv4) and you face a second, far bigger, multi-billion-dollar transition. Is that really the best plan that the community can conceive? IMHO, disappointing, to put it mildly. In case it isn't obvious, this is a vote *against* adopting 2005-1. --Vince From jordi.palet at consulintel.es Mon Apr 17 12:44:10 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 17 Apr 2006 18:44:10 +0200 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last C In-Reply-To: <20060417160840.9878.qmail@hoster908.com> Message-ID: Hi Andrew, I can only talk from a very high level. We are working in Europe (I'm sure is work done everywhere) in multitude of projects regarding what we call AmI (Ambient Intelligence). Basically is about thousands of sensors, actuators and devices, tied to different kind of services and applications. For security reasons, you want to isolate in different subnets different kinds of services, or even a single device being attached to different subnets with several addresses each one. As said, I see the point that 65.000 subnets may still seem too much, but for me 256 is too short. It may be the case, and I really think so, that you will get even in the same link, different prefixes (may be /56) from different service providers. But I still think we need to make sure that the wording of the policy ensures that users aren't trap again in a situation where they need to justify for requesting more subnets (which constitutes a privacy and even security breach) and don't need to pay for that an extra amount which makes them to look again for NAT-like solutions. Regards, Jordi > De: Andrew Dul > Responder a: Andrew Dul > Fecha: Mon, 17 Apr 2006 16:08:40 +0000 > Para: , "ppml at arin.net" > Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 > assignment and utilisation requirement - Last C > >> Yes I know from current research of services and products that will be in >> the market in the next few years, that residential customers will need more >> than 256 subnets. >> >> I'm not so convinced about 65.000 subnets, but I'm given the choice in >> between 256 subnets or 65.000 subnets, I much prefer to be sure than became >> short. > > Would you mind sharing your sources of information predicting the usage of > more than 256 subnets in a normal residential environment. > > Thanks, > Andrew ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From iljitsch at muada.com Mon Apr 17 12:56:38 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 17 Apr 2006 18:56:38 +0200 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <17475.8766.762795.789527@roam.psg.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <17475.8766.762795.789527@roam.psg.com> Message-ID: <2B231C5F-2C6F-47D5-8305-E16548917BE5@muada.com> I completely agree with what Vince said. On 17-apr-2006, at 7:06, Randy Bush wrote: >> Few people realize or remember how close the Internet routing >> system came to collapse during the pre-CIDR days... > i don't think sean thought it was merely close. large portions > of the net were in *serious* failure modes. Well, if you put it like this... It's not that bad today but we're not entirely failure mode free either. If you buy good C or J gear (which starts at around $10k) you're not going to have problems today. But below that price point, life is a lot harder. You can either go with a Linux or BSD box with something like Zebra/Quagga, which is about an order of magnitude less reliable and can only forward so many packets per second, or you can go with a multilayer switch that can forward packets on many gigabit ports at line rate, but those don't run BGP quite as well as the aforementioned C or J boxes. For instance, a couple of years ago I ran into trouble with an Extreme Summit router/switch connected to a large exchange point. It had two or three full BGP feeds and close to 100 peering BGP sessions. Worked like a charm, until at one point something failed, I forget what. But due to that failure, a bunch of BGP sessions flapped: they went down and came back up again. This was enough to get the box into an unstable state where sessions would go down, come back up, go down again and so on. This would persist for about 30 - 60 minutes after which everything would become stable again. For the record: Extreme is not a fly-by-night operation. They make excellent switches and they have some very capable people working on their products. However, presumably they can't invest the massive amounts of work into BGP that Cisco and Juniper can. I think this story illustrates that large routing tables are suboptimal even today. Even without the internet as a whole melting down, a large routing table makes life hard for smaller players that now have a much harder time affording routers that can do full BGP than 5 or 10 years ago. From woody at pch.net Mon Apr 17 13:07:53 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 17 Apr 2006 10:07:53 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <2B231C5F-2C6F-47D5-8305-E16548917BE5@muada.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <17475.8766.762795.789527@roam.psg.com> <2B231C5F-2C6F-47D5-8305-E16548917BE5@muada.com> Message-ID: On Mon, 17 Apr 2006, Iljitsch van Beijnum wrote: > Well, if you put it like this... It's not that bad today but we're > not entirely failure mode free either. If you buy good C or J gear > (which starts at around $10k) you're not going to have problems > today. 2811 w/ AC PWR,2FE,4HWICs,2PVDMs,1NME,2AIMS,IP BASE,64F/256D $2,495 256 to 768MB DDR DRAM factory upgrade for the Cisco 2811 $3,500 $1700 street price for the router, and $55 street price for the RAM, if you're not picky about manufacturer. And I have very little doubt that by the time 768mb of RAM becomes insufficient to hold a full routing table, vendors will have new things to sell me in the sub-$2000 range. -Bill From jdhoule at att.com Mon Apr 17 13:30:07 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Mon, 17 Apr 2006 12:30:07 -0500 Subject: [ppml] PI and potential aggregation In-Reply-To: <444003A2.10005@arin.net> Message-ID: Folks: A very minor change to this could make it more acceptable to the "maintain aggregation" crowd. It is not that PI is bad, it is allocations from ARIN that are down at the "site-size" that is bad. I am not convinced the PI causes routing table explosion, it is advertising of site-sized blocks that causes significant routing table growth. The "distinctly identified prefix" is interesting, but no matter where the addresses come from there will be an expectation on the part of the receiver of the addresses that address blocks assigned by ARIN will be routable on the Internet. As long as IP addresses are more on the "locator" side of the ID/locator spectrum, they WILL have impact on the routing table. Now to the minor change... Allocate out the whole /44, as opposed to a /48 out of a reserved /44. The advantages are: - ARIN stays out of the business of allocating "site-sized" addresses for IPv6. - This relieves qualifying organizations from developing justification for "the remainder of their /44". - ARIN doesn't need to deal with "return to the trough" process. - This results in no higher burn rate of IPv6 addresses, if reserve really means reserve. - We maintain 4 bits worth of potential aggregation we would have lost. - This gives us an opportunity to keep site-sized advertisements out of the IPv6 routing table. - this should increase the probability that these /44 blocks will continue to be advertised and routable in the steady state IPv6 Internet. The only disadvantage I can see is that in a decade or two, if/when IPv6 addresses become scarce we will not have these sets of two or three /48s to harvest when the reservations are removed. (BTW, is there a process to determine if/when reservations should be removed?) That almost sounds like a blessing, not a disadvantage (Can we really picture in 2020 going back and harvest /48s worth of fragmented IPv6 space?). Joe Houle -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Member Services Sent: Friday, April 14, 2006 4:19 PM To: ppml at arin.net Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites and has determined that there is community consensus in favor of the proposal, as edited below, to move it to last call. The AC added the final sentence to section 6.5.8.2. as shown below. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_1.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, April 28, 2006. 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) ###*### Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites Policy statement: Add new subsection in section 6.5 of the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; and b) Qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. 6.5.8.3. Subsequent Assignment Size Additional assignments may be made when the need for additional subnets is justified. When possible assignments will be made from an adjacent address block. Policy Rationale In IPv4 policy there are three main types of organizations that addresses are delegated to. o ISP's receive allocations directly from ARIN or from other ISP's o End Users receive assignments from ISP's o Large and/or multihomed End Users receive assignments directly from ARIN. The third category is currently missing from IPv6 policy and this is believed to be severely hindering deployment by those organizations. In IPv6 policy-speak: o LIR's receive allocations directly from ARIN o End Sites receive assignments from LIR's This policy proposes: o Large and/or multihomed End Sites receive assignments directly from ARIN. This policy applies to organizations with networks that are large and/or multihomed. Like their IPv4 counterparts they do not make assignments to external organizations. They instead assign space internally to their own facilities. Similarly to IPv4 These internal assignments are not submitted to ARIN via swip/rwhois. For transition purposes an organization that qualifies for IPv4 space today is considered eligible, regardless of whether they were considered an ISP or End User under IPv4 policy. It is expected that the IPv6 only (non transition) requirements will be developed as experience is gained. It is recommended that these assignments be made from a separate address block set aside for this purpose and that at least a /44 be reserved around each assignment for possible expansion. One bit should be reserved around assignments /44 and larger. Timetable for implementation: immediately _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From iljitsch at muada.com Mon Apr 17 13:43:45 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 17 Apr 2006 19:43:45 +0200 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> Message-ID: <1D2E9BD5-4EEA-4101-870D-951E3A922C32@muada.com> On 17-apr-2006, at 7:10, Christopher Morrow wrote: > Perhaps the original architects of v6 thought that by not proposing a > multihoming solution, multihoming wouldn't happen? or that someone > would arrive at a better solution than smaller deaggregates? Who > knows... I wasn't there, but I gather that an important consideration was not to change too much in one go. This meant keeping the structure of the socket API the same (I'll spare you my opinion on this issue) and also keeping routing the same as it was/is in IPv4. (The fact that no obvious solutions for the problem presented themselves didn't help, of course.) >> Of course any vendor will love the idea of having to do another IP >> version of course, bring in the cash ;) > because ipv6 was so profitable for them so far? most don't even do v6 > correctly today, after 10 years of development! We are in a very bad > position on all fronts here, shim6 isn't making it better, PI v6 isn't > making it better and vendor's doing half-baked product deployments > aren't either. > it seems that backing up, restarting the 'new protocol' process is > likely to end up with another 10 years wasted, so it's very hard to > see a reasonable path forward at this time. I very much disagree with your assessment of the state of IPv6. Yes, everything is taking its sweet time, but that works both ways: we still have 1400 million unused IPv4 addresses (the equivalent of 84 / 8s), so we don't have to jump the gun now. The reasonable path forward that I see: At least until now, it has been customary in IPv6 to do address configuration for hosts, especially non-servers, with stateless address autoconfiguration. This allows for very easy renumbering. In order for stateless autoconfig to work, routers must still know address prefixes, but with DHCPv6 prefix delegation (PD) it's not necessary to put these in the actual router configuration. So with stateless autoconf and DHCPv6 PD you can effectively renumber an entire network (without any user interruption) by changing some info in a DHCP server. But even in IPv4, that's the easy part. The hard part is keeping the DNS in sync and maintaining address based access controls. But in IPv6 it's hard to populate the DNS anyway (you can't pre-populate an entire address block), and because during the renumbering operation the host maintains both the old and the new address for some time, a good way to handle this is dynamic DNS updates. So the host itself sends updates to the DNS server when it changes addresses rather than having some administrator handle this. Last but not least: the firewalls and so on. There are no solutions for doing this in a way that allows for easy renumbering today, but it's not hard to imagine that a firewall could monitor stateless autoconfig, DHCPv6 PD and DDNS information and adjust its filtering rules accordingly. So we're really close to a situation where it's actually possible to renumber a non-trivial network automatically without user impact. This would negate most of the need for portable address space. With shim6, multihoming doesn't require portable address space either. It is of course possible to argue that all of this, or at least an important ingredient, isn't going to work. That's certainly a possibility. However, as I said before: we still have time, there is no need to jump the gun now. In IPv4, the only tool we have for both multihoming and provider independence is PI addressing. In IPv6, there is a real possibility that we'll have more, so we should try to move away from the mindset where every problem looks like a nail that should be hit with a PI hammer. If in two or three years it turns out that the combination of renumbering and shim6 really don't address the provider independence and/or multihoming problems to a reasonable degre, we can always adopt PI at that point in time. Some people argue that IPv6 deployment is low because there is no PI in IPv6 today. There is simply no evidence of that. More than half the ASes in the IPv4 BGP table are transit ASes (i.e., ISPs, not multihomers) and only a few percent of those are present in the IPv6 BGP table. Also, Google, not a company that rejects new technology by any stretch of the imagination, has through unknown means managed to obtain an IPv6 block (2001:4860::/32) a year ago, but as far as I can tell, they aren't offering any services over IPv6 at this point. So making PI available in IPv6 now is a bad idea as it frustrates more future proof ways to obtain the same results, without any immediate beneficial results. Any good that can come out of IPv6 PI can also be had some years down the road, if at that point, the alternatives haven't panned out. >> That is in the long run, most likely in the coming 10-20 years the >> IPv6 >> routing tables will not have 'exploded' yet, but the folks selling > you have some basis for this? I don't have that same faith... Remember that this isn't about accurately predicting the future, it's about minimizing the potential for catastrophes. It's entirely possible that for various reasons such as the complexity of BGP etc PI never gets out of hand relative to router capabilities, the problem is that we can't know for sure that it won't. From iljitsch at muada.com Mon Apr 17 13:56:39 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 17 Apr 2006 19:56:39 +0200 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <17475.8766.762795.789527@roam.psg.com> <2B231C5F-2C6F-47D5-8305-E16548917BE5@muada.com> Message-ID: <733EFF41-99BB-44E0-9784-4F6B8DB037D9@muada.com> On 17-apr-2006, at 19:07, Bill Woodcock wrote: > 2811 w/ AC PWR,2FE,4HWICs,2PVDMs,1NME,2AIMS,IP BASE,64F/256D > $2,495 > 256 to 768MB DDR DRAM factory upgrade for the Cisco 2811 > $3,500 > And I have very little doubt that by the time 768mb of RAM becomes > insufficient to hold a full routing table, vendors will have new > things to > sell me in the sub-$2000 range. So how fast do these go? 100 Mbps? Obviously at those speeds there are more options but many applications need multi-gigabit speeds. I would even argue that if 100 Mbps isn't a limitation multihoming or any other activity that requires full routing isn't cost effective. From vixie at isc.org Mon Apr 17 13:58:25 2006 From: vixie at isc.org (Paul Vixie) Date: Mon, 17 Apr 2006 17:58:25 +0000 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: Your message of "Mon, 17 Apr 2006 10:07:53 MST." References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <17475.8766.762795.789527@roam.psg.com> <2B231C5F-2C6F-47D5-8305-E16548917BE5@muada.com> Message-ID: <84911.1145296705@sa.vix.com> > 2811 w/ AC PWR,2FE,4HWICs,2PVDMs,1NME,2AIMS,IP BASE,64F/256D $2,495 > 256 to 768MB DDR DRAM factory upgrade for the Cisco 2811 $3,500 > > $1700 street price for the router, and $55 street price for the RAM, if > you're not picky about manufacturer. > > And I have very little doubt that by the time 768mb of RAM becomes > insufficient to hold a full routing table, vendors will have new things to > sell me in the sub-$2000 range. i'm having a sean-doran flashback moment here. let me share it. "will control-plane traffic remain a linear fraction of data-plane traffic or does it go quadratic at some certain graph size? what about the number of routing-system recalculations per route advert/withdraw, and overall stability of the routing system, and router cpu load?" i don't think RAM is the only thing we need to model. From vixie at isc.org Mon Apr 17 14:00:56 2006 From: vixie at isc.org (vixie at isc.org) Date: Mon, 17 Apr 2006 18:00:56 +0000 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: Your message of "Mon, 17 Apr 2006 06:59:35 CST." References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> Message-ID: <85025.1145296856@sa.vix.com> cathy wrote: > Thanks for sending this Vince. I too remember those days when things > were melting down. I often feel that no one else remembers. It is > hard to watch the same mistakes being made over and over again. i remember the memory limits of the AGS+ and the original RP. but these are different mistakes than those. i know folks who applied (pre-CIDR) for a "class C" address for their houses, and got them. are personal dwellings likely to multihome? well, actually, yes. mine did, back in the day, and many will, if you consider switching providers without renumbering to be a derivative form of multihomage. these are different mistakes than those. the ipv4 swamp was mostly populated pre-cidr, and there are still a lot of SMB's and SOHO's therein. the proposed ipv6 swamp can be much smaller, and we should constrain it with all kinds of rules about multiple locations, entity-size, requirements for multihoming, total allocations per RIR per year. since ietf did in fact decline to consider multihoming as a first order problem to be solved during the ipv4->ipv6 transition, and since it's rather late to resurrect DNS's A6 and DNAME RRs, and since shim6 and mobile-ip and et-al appear to be hard sells to the gray-or-balding sector of the operator community, we're left with PI. but it's not the same mistake as the V4 swamp. it's a different mistake, owing its heritage to a whole line of other mistakes, and mistaken or not it's the only proposal i've heard that's got any legs. From dsd at servervault.com Mon Apr 17 14:24:17 2006 From: dsd at servervault.com (Divins, David) Date: Mon, 17 Apr 2006 14:24:17 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6Assignments for End Sites - Last Call Message-ID: Paul, is that a backhanded support e-mail? :-) Anyway, I think as a policy entity for address assignments these ARIN PI policies are appropriate and correct. If there are no feasible technical solutions to support the PI assignments, providers are well within their rights not support the them. Just because you have been given a PI does not guarantee your ability to use it. I would love to see a more complete solution but I don't have one, and the policy hammer seems to be the only weapon we have. BTW, this is a support e-mail Just my $.02 dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of vixie at isc.org Sent: Monday, April 17, 2006 2:01 PM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2005-1: Provider-independent IPv6Assignments for End Sites - Last Call cathy wrote: > Thanks for sending this Vince. I too remember those days when things > were melting down. I often feel that no one else remembers. It is > hard to watch the same mistakes being made over and over again. i remember the memory limits of the AGS+ and the original RP. but these are different mistakes than those. i know folks who applied (pre-CIDR) for a "class C" address for their houses, and got them. are personal dwellings likely to multihome? well, actually, yes. mine did, back in the day, and many will, if you consider switching providers without renumbering to be a derivative form of multihomage. these are different mistakes than those. the ipv4 swamp was mostly populated pre-cidr, and there are still a lot of SMB's and SOHO's therein. the proposed ipv6 swamp can be much smaller, and we should constrain it with all kinds of rules about multiple locations, entity-size, requirements for multihoming, total allocations per RIR per year. since ietf did in fact decline to consider multihoming as a first order problem to be solved during the ipv4->ipv6 transition, and since it's rather late to resurrect DNS's A6 and DNAME RRs, and since shim6 and mobile-ip and et-al appear to be hard sells to the gray-or-balding sector of the operator community, we're left with PI. but it's not the same mistake as the V4 swamp. it's a different mistake, owing its heritage to a whole line of other mistakes, and mistaken or not it's the only proposal i've heard that's got any legs. _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From Ed.Lewis at neustar.biz Mon Apr 17 14:21:08 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 17 Apr 2006 14:21:08 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <85025.1145296856@sa.vix.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <85025.1145296856@sa.vix.com> Message-ID: >ipv6 swamp can be much smaller, and we should constrain it with all kinds of >rules about multiple locations, entity-size, requirements for multihoming, >total allocations per RIR per year. This is why I swung my vote from 2005-x to the other during the tag-team presentation in Montreal. (Ordinarily I wouldn't attach personal names to this, but I've forgotten which is which, so I'll say it this way...) I swung from Owen's to Andrew's proposal during the discussion mostly because Andrew's requires the use of IPv4 multihoming and Owen's only requires qualifying for it. (I hope that I've attributed this correctly, if not, just reverse the names.) Ordinarily I think that requiring the use of IPv4 as a gating function to use IPv6 is a bad idea. However, in this case it raises the bar to getting the IPv6 space that poses a threat to global routing stability. It seems to me that someone who *is* multihoming in IPv4 is demonstrating they have a real need. Someone who isn't, but *qualifies*, doesn't really have the need and therefore shouldn't be invited to get the PI space. The two proposals are similar, there's not a lot of other significantly distinguishing elements. So, something as trivial as "having to do versus having to qualify" swung my emotion in the meeting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From randy at psg.com Mon Apr 17 15:29:46 2006 From: randy at psg.com (Randy Bush) Date: Mon, 17 Apr 2006 09:29:46 -1000 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call References: <17473.34539.981555.932654@roam.psg.com> <17473.61937.962788.674981@roam.psg.com> <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> Message-ID: <17475.60586.1082.258417@roam.psg.com> > E.g., if ISP A is dealing /52's and ISP B is dealing /56's, what > happens when ISP B buys up ISP A? How do you merge customers used to > having /52's into a billing model that is based on /56's? so we are supposed to classfully approach pre-cidr collapse once again because someone wanted to play in the m&a game but could not build a flexible provisioning system? you're kidding, right? randy From Ed.Lewis at neustar.biz Mon Apr 17 15:46:03 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 17 Apr 2006 15:46:03 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <17475.60586.1082.258417@roam.psg.com> References: <17473.34539.981555.932654@roam.psg.com> <17473.61937.962788.674981@roam.psg.com> <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> <17475.60586.1082.258417@roam.psg.com> Message-ID: At 9:29 -1000 4/17/06, Randy Bush wrote: >> E.g., if ISP A is dealing /52's and ISP B is dealing /56's, what >> happens when ISP B buys up ISP A? How do you merge customers used to >> having /52's into a billing model that is based on /56's? > >so we are supposed to classfully approach pre-cidr collapse once >again because someone wanted to play in the m&a game but could >not build a flexible provisioning system? > >you're kidding, right? Truthfully, I don't know. I will affirm that I am not a routing expert, but that's not an excuse. My statement also might not have been a complete capture of the idea - it's based on my recollection, but, it is my recollection. I know that technically we want there to be no boundaries in the network layer address. But there are non-technical considerations to addre-umm, consid-umm, think of. I don't mean "cave in" to them, but to think of them. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From drc at virtualized.org Mon Apr 17 15:54:54 2006 From: drc at virtualized.org (David Conrad) Date: Mon, 17 Apr 2006 12:54:54 -0700 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> Message-ID: Chris, On Apr 16, 2006, at 10:10 PM, Christopher Morrow wrote: > There is no way to get back the /48's assigned under PI > space after a multihoming solution that makes sense arrives, and there > is, honestly, no driver to continue working on a multihoming solution > now that there is PI space. I tend to view multi-homing as a subset of a more general problem, that of separation of end point identifier and routing locator. Renumbering is another aspect of this problem. Mobility too. PI is just an attempt to ignore the problem and hope it goes away. I suspect the PI approach is a short-term solution to multi-homing/ renumbering: when ISPs start feeling pain, they'll take whatever steps they feel necessary to protect their infrastructure, just like they did with IPv4. History repeats itself. It'll be a bit more difficult with IPv6 than it was with IPv4 as prefix-length filters won't work as well (given everybody gets a /48), but I'm sure smart folks at ISPs will come up with other (unfortunately, likely equally annoying from the perspective of end users) solutions. > it seems that backing up, restarting the 'new protocol' process is > likely to end up with another 10 years wasted, so it's very hard to > see a reasonable path forward at this time. As far as I can tell, there are two solutions to the fact that IPv6 didn't separate end point identifier from routing locator: 1) the shim6 approach: create a layer 2.5 solution that separates end point identifier and routing locator and re-implement IPv6 on all hosts to make use of that layer; 2) the middlebox approach: separate the end point identifier from the routing locator at the core/edge boundary, leaving the IPv6 stacks at both the routers in the core and the hosts at the edge untouched, but inserting a mapping from end point identifier to routing locator on source edge to core and an unmapping the routing locator back to the end point identifier from core to destination edge. (I'm not smart enough to figure out how the geotopo approach would work without causing a return to the equivalent of the pre-1994 international telephony settlements regime, but that's my own lack of imagination I suspect). I personally think the middlebox approach is the easiest to deploy/ least disruptive to end users/most familiar to ISPs technique to implement an end point identifier/routing locator split, but I'm cynical enough to be skeptical either approach will be taken... Rgds, -drc -------- My opinions are my own and do not necessarily represent the opinions of any organization I may be a part of. So there. From randy at psg.com Mon Apr 17 15:56:26 2006 From: randy at psg.com (Randy Bush) Date: Mon, 17 Apr 2006 09:56:26 -1000 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call References: <17473.34539.981555.932654@roam.psg.com> <17473.61937.962788.674981@roam.psg.com> <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> <17475.60586.1082.258417@roam.psg.com> Message-ID: <17475.62186.487799.322380@roam.psg.com> >>> E.g., if ISP A is dealing /52's and ISP B is dealing /56's, what >>> happens when ISP B buys up ISP A? How do you merge customers used to >>> having /52's into a billing model that is based on /56's? >> so we are supposed to classfully approach pre-cidr collapse once >> again because someone wanted to play in the m&a game but could >> not build a flexible provisioning system? >> you're kidding, right? > Truthfully, I don't know. I will affirm that I am not a routing > expert, but that's not an excuse. My statement also might not have > been a complete capture of the idea - it's based on my recollection, > but, it is my recollection. my recollection from the apnic meeting where this was raised was that it did not even fly there. randy From drc at virtualized.org Mon Apr 17 16:06:02 2006 From: drc at virtualized.org (David Conrad) Date: Mon, 17 Apr 2006 13:06:02 -0700 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last C In-Reply-To: References: Message-ID: <2C77622C-D3DE-4D0F-8AA1-59E414CFCFCE@virtualized.org> Hi, > As said, I see the point that 65.000 subnets may still seem too > much, but > for me 256 is too short. I'm curious. Given ip6.arpa is on nybble boundaries, why do people view prefix length in IPv6 on byte boundaries? > But I still think we need to make sure that the wording of the policy > ensures that users aren't trap again in a situation where they need to > justify for requesting more subnets (which constitutes a privacy > and even > security breach) and don't need to pay for that an extra amount > which makes > them to look again for NAT-like solutions. I personally think as long as people have to renumber when they change providers, there will be NAT. PI allocation will address this for the early adopters as it did in IPv4, but in the long run, NATv6 is pretty much assured given the current routing paradigm. Rgds, -drc From Ed.Lewis at neustar.biz Mon Apr 17 16:17:47 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 17 Apr 2006 16:17:47 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <17475.62186.487799.322380@roam.psg.com> References: <17473.34539.981555.932654@roam.psg.com> <17473.61937.962788.674981@roam.psg.com> <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> <17475.60586.1082.258417@roam.psg.com> <17475.62186.487799.322380@roam.psg.com> Message-ID: At 9:56 -1000 4/17/06, Randy Bush wrote: >my recollection from the apnic meeting where this was raised was >that it did not even fly there. Could be. Ahh, if you refer to a meeting in Perth, it was probably in a session that I had a conflict with. (I missed the Policy SIG meeting for a DNS thing. This came up when I was looking for follow up to an action item from the Hanoi meeting.) Either way, I think 2005-8, is okay, with the change (away) from the word "guidelines." Whether or not the "ruts" in prefix size will appear or remain, it won't be because of this policy. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From ppml at rs.seastrom.com Mon Apr 17 16:24:40 2006 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Mon, 17 Apr 2006 16:24:40 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <20060417163134.GA10419@vaf-lnx1.cisco.com> (Vince Fuller's message of "Mon, 17 Apr 2006 09:31:34 -0700") References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <878xq4l4d9.fsf@valhalla.seastrom.com> <20060417163134.GA10419@vaf-lnx1.cisco.com> Message-ID: <873bgcar1z.fsf@valhalla.seastrom.com> Vince Fuller writes: > The IETF process failed ten+ years ago when a "solution" was picked that had > been clearly shown to be inadquate at solving the known, hard problems. > Since then, politics have triumphed over technology and all efforts to > design a real solution have been effectively surpressed in the name of > consensus-building around ipv6. There are some people, far brighter than me, > who continue to try to fight the good fight, but the entrenched interests > around ipv6 make that difficult-to-hopeless. > > (OK, now I'm sure I appear to be a conspiracy theorist, so this will be my > last posting on this topic) > > Without a clear message from the IETF contituency that ipv6 is fundamentally > flawed to the point of not being worth the time, effort, and expense of > deployment, there is exactly "zilch" chance that the established path will > be altered. "Moving forward" down a path that inexorably leads to a crisis > vindicates those that deny the existance of a problem (think global warming > here) while the existance of the problem is masked by the early, shallow > slope of the growth curve. I see we're in agreement about the process having failed; we disagree on what to do next. It's clear to me that the past decade of repeatedly sending the message that the process has failed has not had the desired effect. It's not clear to me why you believe that continuing to send the same message, only more strongly worded, is going to change things. >> How about a REAL solution from the IETF with a concentration on the >> "working code" part of "rough consensus and working code" so that we >> can get on with *repealing* 2005-1 after it's no longer necessary? > > Without a commitment to the creation of a solution that obviates 2005-1, > this is a mistake. If there is one thing we've learned from the development > and deployment of CIDR, "temporary" solutions aren't, especially when there > is no clear direction to the "permanent" solution or even a clear > definition of the problem to be solved. CIDR wouldn't have happened without people getting _worried_ about routing table growth. As long as v6 is moribund, there's nothing to worry about. ARIN policy has changed in the past to meet the needs of the community, real and perceived. I can assure you that if 2005-1 is approved there will be one new proposal per cycle to reverse it. Once we see widespread deployment of v6 and routing table growth to a point that is at the same order of magnitude as the current v4 routing table *and* there is a way to handle the multihoming problem without PI space, you'll start seeing widespread support for discontinuing or modifying the v6 PI address space issuance policy, and at that point, one of the supporters will be me. Will we be stuck with routing a swamp in perpetuity? Yup. That's the price we unfortunately have to pay for having a protocol that not only didn't address all problems expected of it when introduced, but has avoided facing them for a decade. > The Internet faces pressure for change today: the exhaution of the 32-bit > IP address space. Spending billions of dollars to deploy a band-aid that > will only trade this crisis for another one a few years down the road hardly > seems like a wise investment, especially when one considers that the > installed base, and thus the cost to deploy a fork-lift "upgrade", will be > orders of magnitude bigger in the future. Fix ipv6 now and you inconvenience > a few early adopters who have to roll-out new implementations; fix it later > (assuming there is a wide-scale deployment and transition from IPv4) and you > face a second, far bigger, multi-billion-dollar transition. Is that really > the best plan that the community can conceive? IMHO, disappointing, to put > it mildly. I agree that it's disappointing, but find it preferable to the alternative of not having a migration path away from v4 before we run out of address space. I would love to see your "fix ipv6 now" eventuality, but based upon past history I believe that this is every bit as much a fantasy as the notion that ipv6 will be a protocol that will last hundreds or thousands of years. > In case it isn't obvious, this is a vote *against* adopting 2005-1. Also in case it's not obvious, I'm in favor of 2005-1. ---Rob From dlw+arin at tellme.com Mon Apr 17 16:41:24 2006 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 17 Apr 2006 13:41:24 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <873bgcar1z.fsf@valhalla.seastrom.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <878xq4l4d9.fsf@valhalla.seastrom.com> <20060417163134.GA10419@vaf-lnx1.cisco.com> <873bgcar1z.fsf@valhalla.seastrom.com> Message-ID: <20060417204124.GX29385@shell01.corp.tellme.com> On Mon, Apr 17, 2006 at 04:24:40PM -0400, Robert E.Seastrom wrote: > I see we're in agreement about the process having failed; we disagree > on what to do next. > [...] > CIDR wouldn't have happened without people getting _worried_ about > routing table growth. As long as v6 is moribund, there's nothing to > worry about. > [...] > I agree that it's disappointing, but find it preferable to the > alternative of not having a migration path away from v4 before we run > out of address space. > [...] > Also in case it's not obvious, I'm in favor of 2005-1. Yeah, that about sums it up for me. I'd prefer to not require PI space in v6. Given current reality, however, my organization will never go for PA space due to the usual reasons. If the protocol fixed the problem of renumbering/multihoming/portability/whatever, we'd jump into PA space in a heartbeat. I'd really much prefer that, as I don't think PI space is particularly workable for the long term. Oh, and in case it isn't obvious, I'm very much in favor of 2005-1. I think PI space until such time as it isn't needed (if ever...) is far preferable to nothing deployed and running out of v4 space. Yes, there's a ways to go before that event, but it's coming soon enough to already look to me like a train wreck. -David From iljitsch at muada.com Mon Apr 17 17:17:15 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 17 Apr 2006 23:17:15 +0200 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <20060417204124.GX29385@shell01.corp.tellme.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <878xq4l4d9.fsf@valhalla.seastrom.com> <20060417163134.GA10419@vaf-lnx1.cisco.com> <873bgcar1z.fsf@valhalla.seastrom.com> <20060417204124.GX29385@shell01.corp.tellme.com> Message-ID: <25968EC2-98AB-4099-A850-D1D4CAE5FC19@muada.com> On 17-apr-2006, at 22:41, David Williamson wrote: > Oh, and in case it isn't obvious, I'm very much in favor of 2005-1. I > think PI space until such time as it isn't needed (if ever...) is far > preferable to nothing deployed and running out of v4 space. Yes, > there's a ways to go before that event, but it's coming soon enough to > already look to me like a train wreck. Question for those of you in favor of the policy proposal: If you're not ISP / IP carrier: Are you planning to obtain an IPv6 PI prefix as per the proposed policy and then deploy, say, 25% or more of the services you now provide over IPv4 over IPv6 using those addresses? And if so, how soon would this happen? If you are an ISP / IP carrier: How many people that are going to do the above are you going to provide IP transit for? And how soon do you expect these people to start doing this? From dlw+arin at tellme.com Mon Apr 17 17:59:00 2006 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 17 Apr 2006 14:59:00 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <25968EC2-98AB-4099-A850-D1D4CAE5FC19@muada.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <878xq4l4d9.fsf@valhalla.seastrom.com> <20060417163134.GA10419@vaf-lnx1.cisco.com> <873bgcar1z.fsf@valhalla.seastrom.com> <20060417204124.GX29385@shell01.corp.tellme.com> <25968EC2-98AB-4099-A850-D1D4CAE5FC19@muada.com> Message-ID: <20060417215900.GB29385@shell01.corp.tellme.com> On Mon, Apr 17, 2006 at 11:17:15PM +0200, Iljitsch van Beijnum wrote: > Question for those of you in favor of the policy proposal: > > If you're not ISP / IP carrier: > > Are you planning to obtain an IPv6 PI prefix as per the proposed > policy and then deploy, say, 25% or more of the services you now > provide over IPv4 over IPv6 using those addresses? And if so, how > soon would this happen? We'd probably request a prefix fairly quickly (within 6 months). We'd then likely work on getting our services v6 capable for 1-2 years, unless there was a solid business reason to go faster, like a client requiring native v6 connectivity/services. That's unlikely, unless much of our client base is watching the progress of 2005-1. I don't think we'd get beyond 25% of our current services deployed on v6 within 2-3 years without a major high-dollar driver. (This is, of course, entirely my own opinion/guess, not necessarily my employer's.) Heck, if a solution comes down the road that makes PI space unnecessary, we might be able to give it back before we get too far along. Of course, nothing like that is on the horizon. -David From gih at apnic.net Mon Apr 17 21:22:19 2006 From: gih at apnic.net (Geoff Huston) Date: Tue, 18 Apr 2006 11:22:19 +1000 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> Message-ID: <6.2.0.14.2.20060418111857.02bdb850@kahuna.telstra.net> >I personally think the middlebox approach is the easiest to deploy/ >least disruptive to end users/most familiar to ISPs technique to >implement an end point identifier/routing locator split, but I'm >cynical enough to be skeptical either approach will be taken... And probably the highest potential risk, unfortunately. From the packet's perspective what's the difference between the helpful header rewriting that my middlebox performs and the evil rewriting that your middlebox performs? i.e. how can you tell the boundary of a site? How can you create a decent security association between the endpoints and the middlebox? Every approach in this space leads one into having to make some very hard decisions! regards, Geoff From drc at virtualized.org Mon Apr 17 22:15:02 2006 From: drc at virtualized.org (David Conrad) Date: Mon, 17 Apr 2006 19:15:02 -0700 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <6.2.0.14.2.20060418111857.02bdb850@kahuna.telstra.net> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> <6.2.0.14.2.20060418111857.02bdb850@kahuna.telstra.net> Message-ID: <39EE3D57-5FD8-49D3-9AEC-3B87707C6015@virtualized.org> Geoff, On Apr 17, 2006, at 6:22 PM, Geoff Huston wrote: > And probably the highest potential risk, unfortunately. You have higher faith in end system IP stack implementers than I apparently... :-) > From the packet's perspective what's the difference between the > helpful header rewriting that my middlebox performs and the evil > rewriting that your middlebox performs? Perhaps I misunderstand. From the packet's perspective, what's the difference between the actual destination router and an in-transit router The Enemy has inserted into the routings stream? If you're relying on IP addresses (v4 or v6) for security, you're doomed anyway. If you really want end-to-end security, you need to secure the actual end points of the communication. That's why God (or Satan, the jury is still out) created IPSEC. > i.e. how can you tell the boundary of a site? Network topologic-wise, where does my (as an end site) responsibility for packet routing end and my ISP's (or ISPs') responsibility begin? > How can you create a decent security association between the > endpoints and the middlebox? Again, perhaps I misunderstand. People seem able to create decent security associations today with VPNs and other tunneling mechanisms. There are a bunch of ways to do it, some scale better than others (I personally like storing the end point identifier/ routing locator mappings in the DNS and using DNSSEC to insure their integrity, but I have some biases in this space). If I understand shim6 correctly (doubtful, but lack of understanding rarely stops me from commenting... :-)) the middleboxen (since there are two) approach is the same as the shim6 approach except where the translation between end point identifier and routing locator occurs. In shim6, it occurs in the IP stack of the end host. In the middleboxen approach, it occurs at the transition point between end site and transit network. From my perspective, both approaches are kludges created to try to fix the fact that IPv6 repeated IPv4's mistake wrt end point identifier/routing locator separation. I just think a solution that doesn't require replacing every existing end system IPv6 stack is more likely to get traction that one that does. Note also that middleboxen and shim6 are not mutually exclusive: I see shim6 as a host solution whereas middleboxen is a site solution. Oh yeah, and I suspect a middleboxen approach could be helpful in transition from v4 to v6... > Every approach in this space leads one into having to make some > very hard decisions! I haven't seen a hard decision yet (not saying they don't exist, just that I haven't seen them). Perhaps you could explain in private (as this isn't really ppml related). Rgds, -drc From christopher.morrow at gmail.com Mon Apr 17 22:55:03 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 17 Apr 2006 22:55:03 -0400 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> Message-ID: <75cb24520604171955x35b66816gac112637a948a1ef@mail.gmail.com> On 4/17/06, David Conrad wrote: > Chris, > > On Apr 16, 2006, at 10:10 PM, Christopher Morrow wrote: > > There is no way to get back the /48's assigned under PI > > space after a multihoming solution that makes sense arrives, and there > > is, honestly, no driver to continue working on a multihoming solution > > now that there is PI space. > > I tend to view multi-homing as a subset of a more general problem, > that of separation of end point identifier and routing locator. > Renumbering is another aspect of this problem. Mobility too. PI is > just an attempt to ignore the problem and hope it goes away. > That may be, though I think it's being viewed as a way to push forward ipv6 deployment. I think v6 has a chicken/egg problem from the deployment perspective: 'there is no call for ipv6 so there is no ipv6 deployment', and 'there is no ipv6 deployment because there is no call for ipv6'. A catch-22 if you prefer that turn of phrase... Anyway, in order to deploy v6 'more quickly' someone has to take a leap, content providers and their associated transit folks can take leap #1, OS folks can take leap #2 and the end users won't care so long as google/gnutella/BT still 'work'. This means that isp's and content providers have to deploy v6. Content providers need to multihome in a reasonable fashion, today that means PI space, which is why we have 2 proposals on the table for v6 PI. There may be, I'm not here to debate it, other fixes for their problem(s), but none are available 'today' which is the timeframe of the request/policy :( So, either the community says: "no ipv6 until multihoming is 'solved'" or we suck it up and start deploying with PI space for the sake of deployment of v6. I'm not convinced that routing PI space will be 'short lived'... > As far as I can tell, there are two solutions to the fact that IPv6 > didn't separate end point identifier from routing locator: > > 1) the shim6 approach: create a layer 2.5 solution that separates end > point identifier and routing locator and re-implement IPv6 on all > hosts to make use of that layer; > > 2) the middlebox approach: separate the end point identifier from the > routing locator at the core/edge boundary, leaving the IPv6 stacks at > both the routers in the core and the hosts at the edge untouched, but > inserting a mapping from end point identifier to routing locator on > source edge to core and an unmapping the routing locator back to the > end point identifier from core to destination edge. > 'middlebox' means 'nat host'... > (I'm not smart enough to figure out how the geotopo approach would > work without causing a return to the equivalent of the pre-1994 > international telephony settlements regime, but that's my own lack of > imagination I suspect). I'm with you on that, I see telco settlements as the 'only' solution to this... -Chris From drc at virtualized.org Mon Apr 17 23:33:33 2006 From: drc at virtualized.org (David Conrad) Date: Mon, 17 Apr 2006 20:33:33 -0700 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <75cb24520604171955x35b66816gac112637a948a1ef@mail.gmail.com> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> <75cb24520604171955x35b66816gac112637a948a1ef@mail.gmail.com> Message-ID: Chris, This is really not ppml related, so this'll be my last post on the topic. If you'd like to explore the ideas more, I'm happy to privately. > So, either the community says: "no ipv6 until multihoming is 'solved'" > or we suck it up and start deploying with PI space for the sake of > deployment of v6. I'm not convinced that routing PI space will be > 'short lived'... Agreed, but maybe it doesn't matter... > 'middlebox' means 'nat host'... Middlebox means "box in the middle" to me. If I used the wrong terminology, excuse me. If I rewrite the IP header of a packet when it traverses the source edge/core boundary into more easily routed gibberish, would anyone care _if I guarantee that the gibberish is rewritten to the original IP header contents at the destination core/edge boundary_? Yes, it is explicitly NAT. The end point identifier's upper 48 (or whatever) bits is being "network address translated" into the routing locator (the lower 80 bits would be untouched). But to avoid the soul-searing EVIL (plain and simple, from beyond the 8th dimension) of NAT, you simply reverse the translation, restoring the upper 48 bits (which, conveniently, don't have to be carried around in the packet since the destination is pretty much guaranteed to know what end point identifier prefix it is at). The two EVILs cancel each other out. The hard part is doing the lookup of the routing locator given the end point identifier at the source edge/core boundary (but I'd argue that's a distributed lookup problem that can be and has been solved a number of ways). >> (I'm not smart enough to figure out how the geotopo approach would >> work without causing a return to the equivalent of the pre-1994 >> international telephony settlements regime, but that's my own lack of >> imagination I suspect). > I'm with you on that, I see telco settlements as the 'only' > solution to this... And I don't really think the folks who fought to kill it the first time would be excited to see it rise zombie-like from the grave. But maybe that's just me. I know folks in Geneva and in monopoly PTTs all over the world would be happy... Rgds, -drc -------- My opinions are my own and do not necessarily represent the opinions of any organization I may be a part of. So there. From gih at apnic.net Tue Apr 18 00:05:29 2006 From: gih at apnic.net (Geoff Huston) Date: Tue, 18 Apr 2006 14:05:29 +1000 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <44433654.9060004@hotnic.net> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> <44433654.9060004@hotnic.net> Message-ID: <6.2.0.14.2.20060418140212.04659db8@kahuna.telstra.net> At 04:31 PM 17/04/2006, Kevin Loch wrote: >Christopher Morrow wrote: > > you have some basis for this? I don't have that same faith... I think > > that quite quickly every entity that has ipv4 space will have ipv6 > > space in some PI fashion (if they have ipv4 PI space) and we'll all be > > stuck routing that and more from now until eternity. That will > > effectively double the current route table, which on much of the > > deployed networks isn't such a good plan. > >While you make a good point about routes being around forever, >I don't think it will double route tables. > >data from cidr-report.org: > >Current prefix/AS ratio in IPv4: 8.4:1 >Current prefix/AS ratio in IPv6: 1.2:1 agreed. >If every AS participating in IPv4 (22,000) also participated >in IPv6 we might expect something closer to 27,000 v6 routes >instead of 182,000. > >Why is the ratio so high in IPv4? If I'm reading the report >properly about 4.2 prefixes/AS are due to deaggregation and >the remaining 4.2 are due to "slow start" assignment policies. Yes - I'd agree with this - around one half of the Ipv4 advertisements are more specifics of a covering aggregate, so of the 8.4 prefix advertisements per originating AS, one half of these advertisements are more specifics of a covering aggregate. The remaining 4.2 prefixes are a combination of slow start and swamp space, so its not entirely correct to attribute the entire number to slow start assignment policies. regards, Geoff From vixie at isc.org Tue Apr 18 00:12:18 2006 From: vixie at isc.org (Paul Vixie) Date: Tue, 18 Apr 2006 04:12:18 +0000 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: Your message of "Mon, 17 Apr 2006 22:55:03 -0400." <75cb24520604171955x35b66816gac112637a948a1ef@mail.gmail.com> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> <75cb24520604171955x35b66816gac112637a948a1ef@mail.gmail.com> Message-ID: <30401.1145333538@sa.vix.com> > So, either the community says: "no ipv6 until multihoming is 'solved'" or we > suck it up and start deploying with PI space for the sake of deployment of > v6. I'm not convinced that routing PI space will be 'short lived'... neither am i, yet i remain in favour of the "suck it up" approach you describe. > > 2) the middlebox approach: separate the end point identifier from the > > routing locator at the core/edge boundary, leaving the IPv6 stacks at both > > the routers in the core and the hosts at the edge untouched, but inserting > > a mapping from end point identifier to routing locator on source edge to > > core and an unmapping the routing locator back to the end point identifier > > from core to destination edge. > > 'middlebox' means 'nat host'... no, it could mean rekindling A6 and DNAME under some different, politically correct guise. DNS would be the EIP and the 128-bit address would be the RL. From owen at delong.com Tue Apr 18 02:09:46 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Apr 2006 23:09:46 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <85025.1145296856@sa.vix.com> Message-ID: <20C4D79A6A0E71C1569FE238@odpwrbook.hq.netli.lan> With apologies to Mr. Vixie... --On April 17, 2006 2:21:08 PM -0400 Edward Lewis wrote: >> ipv6 swamp can be much smaller, and we should constrain it with all >> kinds of rules about multiple locations, entity-size, requirements for >> multihoming, total allocations per RIR per year. > > This is why I swung my vote from 2005-x to the other during the > tag-team presentation in Montreal. (Ordinarily I wouldn't attach > personal names to this, but I've forgotten which is which, so I'll > say it this way...) > > I swung from Owen's to Andrew's proposal during the discussion mostly > because Andrew's requires the use of IPv4 multihoming and Owen's only > requires qualifying for it. (I hope that I've attributed this > correctly, if not, just reverse the names.) > You have the names correct. You are saying you swung from 2006-4 to 2005-1. FWIW, 2005-1 is the one moving to last call. > Ordinarily I think that requiring the use of IPv4 as a gating > function to use IPv6 is a bad idea. However, in this case it raises > the bar to getting the IPv6 space that poses a threat to global > routing stability. > > It seems to me that someone who *is* multihoming in IPv4 is > demonstrating they have a real need. Someone who isn't, but > *qualifies*, doesn't really have the need and therefore shouldn't be > invited to get the PI space. > OTOH, someone who qualifies for V4 can easily get the V4 assignment, then, roll that up in to a V6 assignment and all that requirement really accomplishes is to unnecessarily increase the consumption of V4 address space (IMHO). Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Tue Apr 18 02:27:26 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Apr 2006 23:27:26 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <25968EC2-98AB-4099-A850-D1D4CAE5FC19@muada.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <878xq4l4d9.fsf@valhalla.seastrom.com> <20060417163134.GA10419@vaf-lnx1.cisco.com> <873bgcar1z.fsf@valhalla.seastrom.com> <20060417204124.GX29385@shell01.corp.tellme.com> <25968EC2-98AB-4099-A850-D1D4CAE5FC19@muada.com> Message-ID: --On April 17, 2006 11:17:15 PM +0200 Iljitsch van Beijnum wrote: > On 17-apr-2006, at 22:41, David Williamson wrote: > >> Oh, and in case it isn't obvious, I'm very much in favor of 2005-1. I >> think PI space until such time as it isn't needed (if ever...) is far >> preferable to nothing deployed and running out of v4 space. Yes, >> there's a ways to go before that event, but it's coming soon enough to >> already look to me like a train wreck. > > Question for those of you in favor of the policy proposal: > > If you're not ISP / IP carrier: > > Are you planning to obtain an IPv6 PI prefix as per the proposed > policy and then deploy, say, 25% or more of the services you now > provide over IPv4 over IPv6 using those addresses? And if so, how > soon would this happen? > Wearing my network I operate myself hat: Yes, and I'm not sure. Sooner now than it would have happened without this policy. It will depend, in part, on when my ISP has v6 routing enabled. > If you are an ISP / IP carrier: > > How many people that are going to do the above are you going to > provide IP transit for? And how soon do you expect these people to > start doing this? Wearing my dayjob hat: Probably very few, but, I would expect them to start trickling in in the next 6-12 months. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From izumi at nic.ad.jp Tue Apr 18 02:38:42 2006 From: izumi at nic.ad.jp (Izumi Okutani) Date: Tue, 18 Apr 2006 15:38:42 +0900 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <17475.62186.487799.322380@roam.psg.com> References: <17473.34539.981555.932654@roam.psg.com> <17473.61937.962788.674981@roam.psg.com> <75cb24520604160900v5251c80ep33c9b907c02f09f@mail.gmail.com> <17475.60586.1082.258417@roam.psg.com> <17475.62186.487799.322380@roam.psg.com> Message-ID: <44448972.60505@nic.ad.jp> There may be a bit of misunderstanding over the issues in JP, so let me add some words. M & A was not raised as an issue in JP either, and it's probably quite a rare case to consider for the proposal. The current issues in JP are two: + Some impact over the existing LIRs are noted, expecially in terms of expenses(1/2 LIRs face additional expenses of over US$85,000). + Few LIRs LIRs expressed concerns that classless addressing will lose the benefit of IPv6 over IPv4. i.e, simplicity of network design and service specification You can see more details in the following ppt from APNIC21. http://www.apnic.net/meetings/21/docs/sigs/policy/policy-pres-okutani-v6-survey.pdf I must admit that the general feeling in JP is not favourable to the proposal at the moment, but we plan to collect more opinions from our operaters group as well as LIRs before finally fixing our position. I will ofcourse update the outcome of the discussions here as well. I hope we can continue the co-ordination. izumi JPNIC Randy Bush wrote: >>>> E.g., if ISP A is dealing /52's and ISP B is dealing /56's, what >>>> happens when ISP B buys up ISP A? How do you merge customers used to >>>> having /52's into a billing model that is based on /56's? >>> >>>so we are supposed to classfully approach pre-cidr collapse once >>>again because someone wanted to play in the m&a game but could >>>not build a flexible provisioning system? >>>you're kidding, right? >> >>Truthfully, I don't know. I will affirm that I am not a routing >>expert, but that's not an excuse. My statement also might not have >>been a complete capture of the idea - it's based on my recollection, >>but, it is my recollection. > > > my recollection from the apnic meeting where this was raised was > that it did not even fly there. > > randy > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From owen at delong.com Tue Apr 18 02:44:54 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Apr 2006 23:44:54 -0700 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <6.2.0.14.2.20060418111857.02bdb850@kahuna.telstra.net> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> <6.2.0.14.2.20060418111857.02bdb850@kahuna.telstra.net> Message-ID: <8C95F098BF6107B4ADF4B343@odpwrbook.hq.netli.lan> --On April 18, 2006 11:22:19 AM +1000 Geoff Huston wrote: > >> I personally think the middlebox approach is the easiest to deploy/ >> least disruptive to end users/most familiar to ISPs technique to >> implement an end point identifier/routing locator split, but I'm >> cynical enough to be skeptical either approach will be taken... > > And probably the highest potential risk, unfortunately. > > From the packet's perspective what's the difference between the helpful > header rewriting that my middlebox performs and the evil rewriting that > your middlebox performs? i.e. how can you tell the boundary of a site? > How can you create a decent security association between the endpoints > and the middlebox? > How is this different from the ability to intercept the packet at each hop today? If you can get in the data stream, you can divert the packets. Simple as that. It does not change the nature of the security issue as it exists today. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Tue Apr 18 05:00:40 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 18 Apr 2006 10:00:40 +0100 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: Message-ID: > Hi Scott, > > See below, in-line. When I see a post like this, I just ignore the whole thing. When a message contains long copies of multiple previous messages, most of which is not relevant to the author's comments, then it is too much work to figure it all out. --Michael Dillon P.S. I don't expect everybody to edit as tightly as I do, but I think that on a mailing list like this we should all at least make an effort towards clarity. From Michael.Dillon at btradianz.com Tue Apr 18 05:19:10 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 18 Apr 2006 10:19:10 +0100 Subject: [ppml] Soviet central planning - not! Message-ID: I have noticed a disturbing undercurrent in many recent PPML postings. People are making proposals that are a long way out of ARIN's scope and would only be appropriate in a world where ARIN is like a Soviet central planning organization. A Soviet central planner can mandate what ISPs do with address allocations in the routing system. They can decide when there are enough new ISPs. They can set rules for the ISP's fee structure. And many other things. They can also make very big mistakes that are not discovered until it is much too late. ARIN, on the other hand, can't do any of these things. We have a very limited scope and our actions, in general, do not control or limit what ISPs can do. We can also make mistakes, but because of our limited scope, they can never be big ones. Any of our decisions are subject to constant review by ISPs, end users, ARIN members, other RIRs and so on. As a result, we do not need to make our policies perfect in every way. We are allowed to make experiments and muddle our way towards a good policy. In any situation where we find it difficult to move towards consensus, we are probably trying to come up with a big Soviet central planning style solution. This does not work. Such problems need to be broken down into elements which we can move ahead with separately. We need to test ideas in the real world and not get carried away with theoretical implications 20 years from now. We need to make some mistakes. And then correct them. --Michael Dillon From Michael.Dillon at btradianz.com Tue Apr 18 05:33:58 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 18 Apr 2006 10:33:58 +0100 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> Message-ID: > There is no way to get back the /48's assigned under PI > space after a multihoming solution that makes sense arrives, Not so. The mechanism for retrieving these /48's is: Step 1. ARIN introduces a new PI policy that issues some kind of different PI addresses that are aggregatable. Step 2. ISPs concerned about routing table size start filtering the old non-aggregatable PI address blocks. Step 3. ARIN begins a cleanup program to contact the holders of these old, mostly useless, /48's and asks them to return them to ARIN. In fact, you could also make allocation of a future-style PI block conditional on return of the old 2005-1 style PI blocks. --Michael Dillon From Michael.Dillon at btradianz.com Tue Apr 18 05:59:53 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 18 Apr 2006 10:59:53 +0100 Subject: [ppml] PI and potential aggregation In-Reply-To: Message-ID: > Now to the minor change... Allocate out the whole /44, as opposed to > a /48 out of a reserved /44. The advantages are: > - ARIN stays out of the business of allocating "site-sized" addresses > for IPv6. > - This relieves qualifying organizations from developing justification > for "the remainder of their /44". > - ARIN doesn't need to deal with "return to the trough" process. > - This results in no higher burn rate of IPv6 addresses, if reserve > really means reserve. > - We maintain 4 bits worth of potential aggregation we would have lost. > - This gives us an opportunity to keep site-sized advertisements out of > the IPv6 routing table. > - this should increase the probability that these /44 blocks will > continue to be advertised and routable in the steady state IPv6 > Internet. Very good analysis and I agree with this. The idea of reserve addresses here, reverses the position of end user members and ISP members. In IPv4, ISP members continually come back to the trough and therefore expend some effort to be sure that ARIN's policies and processes are reasonable. In IPv6, ISPs don't come back to the trough and this reserve concept would lead to end users doing that. The end result would be that end user organizations will be more motivated to see that ARIN is in line with their interests. --Michael Dillon From Michael.Dillon at btradianz.com Tue Apr 18 06:38:26 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 18 Apr 2006 11:38:26 +0100 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: Message-ID: > (I'm not smart enough to figure out how the geotopo approach would > work without causing a return to the equivalent of the pre-1994 > international telephony settlements regime, but that's my own lack of > imagination I suspect). I'm not sure why you think that ISPs would give up the current Internet settlement regime and move back to a pre-1994 telephony settlement regime. Back then, telephone companies counted every penny of every single point-to-point flow that went across their boundaries. Then they compared lists, counted the totals and one party paid the difference to the other party. On today's Internet, settlements are all bilateral. The two parties estimate the traffic balance between them without actually accounting for every penny of cost. Doing it this way, they both save the substantial costs of counting pennies. Then, if the both agree that they are more or less in balance, they peer with each other at no charge. Again, the cost savings of not counting every packet, offsets the minor fluctuations in traffic between the two companies. However, if they estimate that there will be a traffic imbalance between the two parties, then they agree on a fee to be paid for this imbalance. This is called paid peering. The current settlements regime has evolved over many years of operational and business experience. It is unlikely to change substantially when geo-topo traffic is introduced into the scheme. Of course, peers will have to incorporate geo-topo traffic into their agreements and into their engineering planning, but there is nothing to indicate that this will drive them to packet counting or any kind of large scale deployment of IP accounting. --Michael Dillon From owen at delong.com Tue Apr 18 07:57:02 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Apr 2006 04:57:02 -0700 Subject: [ppml] PI and potential aggregation In-Reply-To: References: Message-ID: > Very good analysis and I agree with this. > The idea of reserve addresses here, reverses the position > of end user members and ISP members. In IPv4, ISP members > continually come back to the trough and therefore expend > some effort to be sure that ARIN's policies and processes > are reasonable. In IPv6, ISPs don't come back to the trough > and this reserve concept would lead to end users doing that. > The end result would be that end user organizations will be > more motivated to see that ARIN is in line with their > interests. > You seem to be implying that is a bad thing. I don't think that having more end-user participation in ARIN would be a bad thing at all. I think more participation from more diverse areas of ARIN's constituency is a good thing. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From memsvcs at arin.net Tue Apr 18 12:14:10 2006 From: memsvcs at arin.net (Member Services) Date: Tue, 18 Apr 2006 12:14:10 -0400 Subject: [ppml] Number of Subscribers Message-ID: <44451052.5070901@arin.net> ARIN received an off line request regarding subscribers to this list. The current number is 347, excluding ARIN and other RIR staff. Regards, Member Services American Registry for Internet Numbers From vixie at isc.org Tue Apr 18 12:49:47 2006 From: vixie at isc.org (vixie at isc.org) Date: Tue, 18 Apr 2006 16:49:47 +0000 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: Your message of "Tue, 18 Apr 2006 11:38:26 +0100." References: Message-ID: <99782.1145378987@sa.vix.com> > On today's Internet, settlements are all bilateral. > The two parties estimate the traffic balance between > them without actually accounting for every penny of > cost. Doing it this way, they both save the substantial > costs of counting pennies. Then, if the both agree > that they are more or less in balance, they peer > with each other at no charge. and if only one party agrees, you get into cogent/level3 style peering wars. also, i recall leading a team who built a global backbone where i could afford to peer with PSI in every city where they had a presence, which i offered to do. they declined, citing not cost-disparity (since i'd equalized that from my side) but benefit-disparity, and offered to sell me transit. apparently this business model wasn't sustainable for either them or me, given what happened to AS174 and AS6461 in the year or two following. so, i think the settlement model described above is somehow incomplete, and i advise against anyone treating the situation as being "quite that simple." > However, if they estimate that there will be a traffic > imbalance between the two parties, then they agree > on a fee to be paid for this imbalance. This is called > paid peering. or if one party thinks they can hold their customers as ransom and force the other guy to pay, they will definitely try. this is called "highway robbery" or sometimes "capitalism". > The current settlements regime has evolved over many > years of operational and business experience. ... the current settlement regime locks new providers out of the market, to the detriment of end-users everywhere. go ahead, tell me how you'd spend $1B to join the DFZ with pure SFP in 10 years, and then tell me how you'd ever make that money back at the current/declining transit and on-net prices now seen. but we digress. From randy at psg.com Tue Apr 18 13:16:40 2006 From: randy at psg.com (Randy Bush) Date: Tue, 18 Apr 2006 07:16:40 -1000 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> <6.2.0.14.2.20060418111857.02bdb850@kahuna.telstra.net> <39EE3D57-5FD8-49D3-9AEC-3B87707C6015@virtualized.org> Message-ID: <17477.7928.321138.592482@roam.psg.com> > From my perspective, both approaches are kludges created to try to > fix the fact that IPv6 repeated IPv4's mistake wrt end point > identifier/routing locator separation. I just think a solution that > doesn't require replacing every existing end system IPv6 stack is > more likely to get traction that one that does. Note also that > middleboxen and shim6 are not mutually exclusive: I see shim6 as a > host solution whereas middleboxen is a site solution. Oh yeah, and I > suspect a middleboxen approach could be helpful in transition from v4 > to v6... can an host-only end user, i.e. a multi-home broadband gamer, shim6 with a middle-boxed site? randy From sleibrand at internap.com Tue Apr 18 13:26:32 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 18 Apr 2006 13:26:32 -0400 (EDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <17477.7928.321138.592482@roam.psg.com> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> <6.2.0.14.2.20060418111857.02bdb850@kahuna.telstra.net> <39EE3D57-5FD8-49D3-9AEC-3B87707C6015@virtualized.org> <17477.7928.321138.592482@roam.psg.com> Message-ID: On 04/18/06 at 7:16am -1000, Randy Bush wrote: > can an host-only end user, i.e. a multi-home broadband gamer, > shim6 with a middle-boxed site? >From the discussion I've seen of middle-boxes on the shim6 list, that seems to be the idea. -Scott From weiler at tislabs.com Tue Apr 18 13:32:21 2006 From: weiler at tislabs.com (Sam Weiler) Date: Tue, 18 Apr 2006 13:32:21 -0400 (EDT) Subject: [ppml] Mutating RSA? In-Reply-To: References: Message-ID: On Mon, 17 Apr 2006, Edward Lewis wrote: > If it is up to people like me to review it, then I should ask - how > does the membership make comments on the RSA, how does the membership > influence it? Is there a means to appeal a change to the RSA? Since the RSA terms may be of interest to those who haven't yet gotten address space, I propose that the questions should be "how does the community make comments on the RSA?" and "how does the community influence it?". I'm CC'ing Member Services on this message, in hopes that we'll get a public reply. -- Sam From pesherb at yahoo.com Tue Apr 18 14:28:03 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Tue, 18 Apr 2006 11:28:03 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: Message-ID: <20060418182803.86509.qmail@web54714.mail.yahoo.com> > I'm not sure why ... ISPs would give > up the current Internet settlement regime and move > back to a pre-1994 telephony settlement regime. They have no choice. Until recently good old wireline voice has subsidized the Internet (this is why btw only telcos have survived 2002 meltdown). As wireline goes away there is no other alternative as to make the Internet profitable. And the proper way to do it is via settlements. Every independent network reasonably expects to collect from traversing traffic. > Back then, telephone companies counted every penny > of every single point-to-point They counted minutes not pennies. For telco a minute is a basic cost driver that suits very well for cost models, billing, pricing, settlements etc. The Internet equivalent of the minute is one bit. Any prudent ISP would want to count every bit for each customer for proper billing, settlements, etc. > On today's Internet, settlements are all bilateral. Backbone Tier ISPs at the top get the benefit from the rest of the pyramid. Convenient but imbalanced model. > nothing to indicate that this will drive them to > packet counting or any kind of large scale deployment > of IP accounting. Say that to a currency trader counting every 1/100 of a percentage point. Or to a Power Generator charging for every watt. Whoever plays the Internet has to count bits. An alternative would be going bust. Cheers, Peter --- Michael.Dillon at btradianz.com wrote: > > (I'm not smart enough to figure out how the geotopo approach would > > work without causing a return to the equivalent of the pre-1994 > > international telephony settlements regime, but that's my own lack of > > imagination I suspect). > > I'm not sure why you think that ISPs would give > up the current Internet settlement regime and move > back to a pre-1994 telephony settlement regime. > > Back then, telephone companies counted every penny > of every single point-to-point flow that went across > their boundaries. Then they compared lists, counted > the totals and one party paid the difference to the > other party. > > On today's Internet, settlements are all bilateral. > The two parties estimate the traffic balance between > them without actually accounting for every penny of > cost. Doing it this way, they both save the substantial > costs of counting pennies. Then, if the both agree > that they are more or less in balance, they peer > with each other at no charge. Again, the cost savings > of not counting every packet, offsets the minor > fluctuations in traffic between the two companies. > However, if they estimate that there will be a traffic > imbalance between the two parties, then they agree > on a fee to be paid for this imbalance. This is called > paid peering. > > The current settlements regime has evolved over many > years of operational and business experience. It is > unlikely to change substantially when geo-topo traffic > is introduced into the scheme. Of course, peers will > have to incorporate geo-topo traffic into their agreements > and into their engineering planning, but there is > nothing to indicate that this will drive them to > packet counting or any kind of large scale deployment > of IP accounting. > > --Michael Dillon > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dsinn at dsinn.com Tue Apr 18 14:43:26 2006 From: dsinn at dsinn.com (F. David Sinn) Date: Tue, 18 Apr 2006 11:43:26 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <25968EC2-98AB-4099-A850-D1D4CAE5FC19@muada.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <878xq4l4d9.fsf@valhalla.seastrom.com> <20060417163134.GA10419@vaf-lnx1.cisco.com> <873bgcar1z.fsf@valhalla.seastrom.com> <20060417204124.GX29385@shell01.corp.tellme.com> <25968EC2-98AB-4099-A850-D1D4CAE5FC19@muada.com> Message-ID: <89FB388B-BB25-4427-A12D-426E2239AF10@dsinn.com> On Apr 17, 2006, at 2:17 PM, Iljitsch van Beijnum wrote: > On 17-apr-2006, at 22:41, David Williamson wrote: > >> Oh, and in case it isn't obvious, I'm very much in favor of >> 2005-1. I >> think PI space until such time as it isn't needed (if ever...) is far >> preferable to nothing deployed and running out of v4 space. Yes, >> there's a ways to go before that event, but it's coming soon >> enough to >> already look to me like a train wreck. > > Question for those of you in favor of the policy proposal: So is this to mean that anyone that reply's is implicitly in favor of 2005-1? :) Officially, I'm in support of it. > > If you're not ISP / IP carrier: > > Are you planning to obtain an IPv6 PI prefix as per the proposed > policy and then deploy, say, 25% or more of the services you now > provide over IPv4 over IPv6 using those addresses? And if so, how > soon would this happen? > > If you are an ISP / IP carrier: > > How many people that are going to do the above are you going to > provide IP transit for? And how soon do you expect these people to > start doing this? Being that my day job is in R&E regional connector, I would say that all of my customers currently running IPv6 would either apply for 2005-1 or just apply for a PI since they are institutes of higher education (if they haven't already). All are already multi-homed for v4 and will likely want to do the same once they are reliant upon v6. Beyond that, I would guess a good half of my customers will also follow suit and want some form of PI space, again either under 2005-1 or under the fairly easy process as a research institution. As to their timeline, that's really the whole question of all of these conversations. Today they have no real need since there are no real services (you can only watch a swimming turtle or listen to Virgin Radio for so long), so most don't have it on their radar. If there were meaningful services for them to utilize v6 then the story would be different. Which is in part why helping the multihoming concern forward with 2005-1 is important, since that stumbling block is one of the detractors from v6 adoption. David > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Ed.Lewis at neustar.biz Tue Apr 18 15:12:34 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 18 Apr 2006 15:12:34 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <20C4D79A6A0E71C1569FE238@odpwrbook.hq.netli.lan> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <85025.1145296856@sa.vix.com> <20C4D79A6A0E71C1569FE238@odpwrbook.hq.netli.lan> Message-ID: At 23:09 -0700 4/17/06, Owen DeLong wrote: >You have the names correct. You are saying you swung from 2006-4 >to 2005-1. FWIW, 2005-1 is the one moving to last call. I'm glad I used the names then, I had the policy identifiers reversed. So, yeah, I'm for the one that made it to last call. >OTOH, someone who qualifies for V4 can easily get the V4 assignment, >then, roll that up in to a V6 assignment and all that requirement >really accomplishes is to unnecessarily increase the consumption of >V4 address space (IMHO). Yeah, the difference between "doing" and "qualifying for" is not great. It's just that having overcome the inertia of not doing it means you are relatively more, umm, worthy. As the two choices were that close, something so slight is all it took to sway me between the two. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From lea.roberts at stanford.edu Tue Apr 18 15:24:11 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Tue, 18 Apr 2006 12:24:11 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <44448972.60505@nic.ad.jp> Message-ID: hi Izumi! thanks for the clarification(s). I still have a question below. On Tue, 18 Apr 2006, Izumi Okutani wrote: > The current issues in JP are two: > > + Some impact over the existing LIRs are noted, expecially in > terms of expenses(1/2 LIRs face additional expenses of over > US$85,000). are these additional expenses one time costs? or do people feel there is some ongoing cost to dealing with multiple assignment sizes even after the supporting software is upgraded? > + Few LIRs LIRs expressed concerns that classless addressing will > lose the benefit of IPv6 over IPv4. > i.e, simplicity of network design and service specification > thanks again, /Lea From owen at delong.com Tue Apr 18 17:03:20 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Apr 2006 14:03:20 -0700 Subject: [ppml] Mutating RSA -- Policy Proposal Message-ID: <5EDBECF0BD058B60E6E8C681@imac-en0.delong.sj.ca.us> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 Policy Proposal Name: RSA Modification Procedure Author name: Owen DeLong email: owen at delong.com telephone: 408-921-6984 organization: DeLong Consulting (OrgID: DELONG) Proposal Version: 1.0 Submission Date: 4/18/2006 Proposal type: N new, modify, or delete. Policy term: P temporary, permanent, or renewable. Policy statement: Add a section 11. Adminstrative Practices to the NRPM as follows: 11. Administrative Practices 11.1 Changes to the Registration Services Agreement a) All changes to the registration services agreement shall be posted to PPML and discussed as any other ARIN policy change. b) The BoT shall have the authority to veto any proposed change to the RSA if doing so at the advice of counsel. c) When a change to the RSA is to take effect, ARIN shall post the new RSA on the ppml and arin-discuss lists as well as any additional lists ARIN staff feels would be appropriate (such as nanog at the time of writing) at least 30 days before said change would take effect. Rationale: It is currently being discussed on PPML that ARIN has a new policy of being able to modify the RSA without notice and suggesting that everyone review the ARIN web site every 30 days to see if it has changed. This situation is untenable. The above policy is intended to bring the RSA into compliance with other ARIN policy-related procedures. I am proposing a new section 11 to the NRPM because there really isn't a good place for it to fit in the existing sections. This is by no means intended to be a complete study of ARIN administrative practices and I would anticipate that other proposals in the future would expand and refine section 11. However, this is intended to create a place for such issues in the NRPM and to address this specific issue in that place. Timetable for implementation: Immediately upon acceptance by the BoT after last call Meeting presenter: Owen DeLong END OF TEMPLATE -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Tue Apr 18 17:09:48 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Apr 2006 14:09:48 -0700 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <20060418182803.86509.qmail@web54714.mail.yahoo.com> References: <20060418182803.86509.qmail@web54714.mail.yahoo.com> Message-ID: >> Back then, telephone companies counted every penny >> of every single point-to-point > > They counted minutes not pennies. For telco a minute is a basic cost > driver that suits very well for cost models, billing, pricing, > settlements etc. The Internet equivalent of the minute is one bit. Any > prudent ISP would want to count every bit for each customer for proper > billing, settlements, etc. > The problem with this theory is that in the telephone model, there is a (relatively) clear relationship between the initiator of the call and someone who wants to pay for the traffic. In the internet, often, connections are initiated somewhat outside of the users control by advertisers. In these cases, advertisers should be seeing the bill for the bits, not the user who received the pop-up or click-ad as an IMG tag in some web page he went to or email he received. On the internet, there simply isn't a good mechanism for tying either end of the connection to who should pay for it. To further complicate this matter, there is the issue of spoofed address traffic. Should I really be billed for someone originating a terrabyte of traffic I didn't know existed, just because they picked one of my IP addresses at random? Per-minute or per-unit pricing works in a circuit-switched environment. In a packet-switched environment, it gets substantially more difficult to implement in a fair or equitable manner. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From alh-ietf at tndh.net Tue Apr 18 17:36:43 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 18 Apr 2006 14:36:43 -0700 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: Message-ID: <071601c66330$2fc7ef90$d447190a@tndh.net> Owen DeLong wrote: > ... > On the internet, there simply isn't a good mechanism for tying either > end of the connection to who should pay for it. To further complicate > this matter, there is the issue of spoofed address traffic. Should > I really be billed for someone originating a terrabyte of traffic I > didn't know existed, just because they picked one of my IP addresses > at random? In general I agree with your post, but this point seems like it need some further thought. Say there were a settlement process in place. A transit provider would look to the volume over the interconnect, likely not at the source address. This would follow down the chain until the loop provider was left to sort out which customer it came from. Their first inclination would be to look at the address, but if spoofed would likely not even be one of their customers. This would lead them to argue that the upstream was wrong, then when pushed back to eat the bill, they would have to implement strict RPF at their customer edges to block the nonsense. They might also move to volume charging on each loop which would pass the cost along to the real source. Assuming the spoofed traffic was from a zombie, it would provide the cost incentive to get the machine cleaned up. In the grand scheme of things there is no fair way to judge who initiated traffic flow in any particular direction, so fine-grained per-flow volume based charging is not operationally deployable. Tony From pesherb at yahoo.com Tue Apr 18 18:14:49 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Tue, 18 Apr 2006 15:14:49 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: Message-ID: <20060418221449.99759.qmail@web54704.mail.yahoo.com> > In a packet-switched environment, it gets substantially more difficult > to implement in a fair or equitable manner. The Internet billing model is simple: (Download - Upload) * $/bit = Billed Amount It is based on two assumptions: 1. People access the Internet to download content 2. Paying party controls their download activity If security becomes a prohibitive concern for the above then the product is just not ready for use. Peter --- Owen DeLong wrote: > > >> Back then, telephone companies counted every penny > >> of every single point-to-point > > > > They counted minutes not pennies. For telco a minute is a basic cost > > driver that suits very well for cost models, billing, pricing, > > settlements etc. The Internet equivalent of the minute is one bit. Any > > prudent ISP would want to count every bit for each customer for proper > > billing, settlements, etc. > > > The problem with this theory is that in the telephone model, there is > a (relatively) clear relationship between the initiator of the call > and someone who wants to pay for the traffic. > > In the internet, often, connections are initiated somewhat outside > of the users control by advertisers. In these cases, advertisers > should be seeing the bill for the bits, not the user who received > the pop-up or click-ad as an IMG tag in some web page he went to > or email he received. > > On the internet, there simply isn't a good mechanism for tying either > end of the connection to who should pay for it. To further complicate > this matter, there is the issue of spoofed address traffic. Should > I really be billed for someone originating a terrabyte of traffic I > didn't know existed, just because they picked one of my IP addresses > at random? > > Per-minute or per-unit pricing works in a circuit-switched environment. > In a packet-switched environment, it gets substantially more difficult > to implement in a fair or equitable manner. > > Owen > > > -- > If it wasn't crypto-signed, it probably didn't come from me. > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From alh-ietf at tndh.net Tue Apr 18 18:46:25 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 18 Apr 2006 15:46:25 -0700 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] In-Reply-To: <20060418221449.99759.qmail@web54704.mail.yahoo.com> Message-ID: <072801c66339$ec6e5fe0$d447190a@tndh.net> Peter Sherbin wrote: > The Internet billing model is simple: > > (Download - Upload) * $/bit = Billed Amount So the carriers owe the content providers $M's/month ??? > > It is based on two assumptions: > 1. People access the Internet to download content > 2. Paying party controls their download activity Obviously you haven't head of P2P, or people hosting family oriented content. Not all traffic is download. > > If security becomes a prohibitive concern for the above then the product > is just not > ready for use. That billing model is not ready for use, and security or lack thereof has nothing to do with it. Tony From pesherb at yahoo.com Tue Apr 18 18:53:10 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Tue, 18 Apr 2006 15:53:10 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <071601c66330$2fc7ef90$d447190a@tndh.net> Message-ID: <20060418225310.74464.qmail@web54706.mail.yahoo.com> > In the grand scheme of things there is no fair way to judge who initiated > traffic flow in any particular direction, so fine-grained per-flow volume > based charging is not operationally deployable. As a financially conscious ISP I want volume based pricing as the major marketing, product development and ROI tool. Peter --- Tony Hain wrote: > Owen DeLong wrote: > > ... > > On the internet, there simply isn't a good mechanism for tying either > > end of the connection to who should pay for it. To further complicate > > this matter, there is the issue of spoofed address traffic. Should > > I really be billed for someone originating a terrabyte of traffic I > > didn't know existed, just because they picked one of my IP addresses > > at random? > > In general I agree with your post, but this point seems like it need some > further thought. Say there were a settlement process in place. A transit > provider would look to the volume over the interconnect, likely not at the > source address. This would follow down the chain until the loop provider was > left to sort out which customer it came from. Their first inclination would > be to look at the address, but if spoofed would likely not even be one of > their customers. This would lead them to argue that the upstream was wrong, > then when pushed back to eat the bill, they would have to implement strict > RPF at their customer edges to block the nonsense. They might also move to > volume charging on each loop which would pass the cost along to the real > source. Assuming the spoofed traffic was from a zombie, it would provide the > cost incentive to get the machine cleaned up. > > In the grand scheme of things there is no fair way to judge who initiated > traffic flow in any particular direction, so fine-grained per-flow volume > based charging is not operationally deployable. > > Tony > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From pesherb at yahoo.com Tue Apr 18 19:06:54 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Tue, 18 Apr 2006 16:06:54 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] In-Reply-To: <072801c66339$ec6e5fe0$d447190a@tndh.net> Message-ID: <20060418230654.41683.qmail@web54707.mail.yahoo.com> > So the carriers owe the content providers $M's/month ??? In the exact same fashion as cable providers owe studios. > Obviously you haven't head of P2P, or people hosting family oriented > content. Not all traffic is download. Look again at the formula. If (Download - Upload) < 0, then your bill equals 0. Traffic uploaders (aka content providers) are good for the network because: Assumption 1. People access the Internet to download content (and such downloaders are supposed to pay for satisfying that need). > That billing model is not ready for use, and security or lack thereof has > nothing to do with it. If security has nothing to do with the Internet then why does the community spends so much time and effort on it? Peter --- Tony Hain wrote: > Peter Sherbin wrote: > > The Internet billing model is simple: > > > > (Download - Upload) * $/bit = Billed Amount > > So the carriers owe the content providers $M's/month ??? > > > > > It is based on two assumptions: > > 1. People access the Internet to download content > > 2. Paying party controls their download activity > > Obviously you haven't head of P2P, or people hosting family oriented > content. Not all traffic is download. > > > > > If security becomes a prohibitive concern for the above then the product > > is just not > > ready for use. > > That billing model is not ready for use, and security or lack thereof has > nothing to do with it. > > Tony > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From randy at psg.com Tue Apr 18 19:24:05 2006 From: randy at psg.com (Randy Bush) Date: Tue, 18 Apr 2006 13:24:05 -1000 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] References: <072801c66339$ec6e5fe0$d447190a@tndh.net> <20060418230654.41683.qmail@web54707.mail.yahoo.com> Message-ID: <17477.29973.159585.79997@roam.psg.com> you're back at the discussion of which is worth more eye balls or eye candy. the question is not answerable, and both are needed to make the world go 'round. it's a silly as traffic ratios on peering agreements. there is no basis, only politics, pressure, and negotiation. randy From pesherb at yahoo.com Tue Apr 18 21:06:00 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Tue, 18 Apr 2006 18:06:00 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] In-Reply-To: <17477.29973.159585.79997@roam.psg.com> Message-ID: <20060419010600.19552.qmail@web54710.mail.yahoo.com> > it's a silly as traffic ratios on peering agreements. For what I see telcos are under a huge pressure to substitute eroding wireline with new revenues. The Internet? Then they have to rely on a traditional model charging for every bit traversing their networks. And does counting bits differ that drastically from counting minutes? I dare to speculate that the Internet belonging to a common good like interstate highways will end up as a set of community networks supported by tax dollars coupled with a mix of Application Providers' and private networks. That kind of infrastructure people already are building in Asia where IPv6 nicely resounds with threads-in-a-sheet self conscience. Peter --- Randy Bush wrote: > you're back at the discussion of which is worth more eye balls > or eye candy. the question is not answerable, and both are > needed to make the world go 'round. > > it's a silly as traffic ratios on peering agreements. there > is no basis, only politics, pressure, and negotiation. > > randy > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From michel at arneill-py.sacramento.ca.us Tue Apr 18 21:06:16 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 18 Apr 2006 18:06:16 -0700 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advancesinARIN] Message-ID: > Peter Sherbin wrote: > Look again at the formula. If (Download - Upload) < 0, > then your bill equals 0. Ah cool. I leave my bittorrent client open all day and not only I pump up my ratio but I also have free Internet. Probably we should put thee UN in charge of billing the people that download from me too. From pesherb at yahoo.com Tue Apr 18 22:06:40 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Tue, 18 Apr 2006 19:06:40 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advancesinARIN] In-Reply-To: Message-ID: <20060419020640.99608.qmail@web54709.mail.yahoo.com> > Ah cool. I leave my bittorrent client open all day and not only I pump > up my ratio but I also have free Internet. Bittorent is an excellent opportunity for ISPs looking for new revenues. They need two things: 1. Turn ISP servers into a source for P2P traffic 2. Set an agreement with studios on content distribution Benefit to consumer: a realiable source for secure, standard, high quality content that is easy to download, unpack and play. Benefit to ISP: good cause to increase the price with no impact on churn. Peter --- Michel Py wrote: > > Peter Sherbin wrote: > > Look again at the formula. If (Download - Upload) < 0, > > then your bill equals 0. > > Ah cool. I leave my bittorrent client open all day and not only I pump > up my ratio but I also have free Internet. Probably we should put thee > UN in charge of billing the people that download from me too. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tme at multicasttech.com Tue Apr 18 23:21:06 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 18 Apr 2006 23:21:06 -0400 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] In-Reply-To: <20060418230654.41683.qmail@web54707.mail.yahoo.com> References: <20060418230654.41683.qmail@web54707.mail.yahoo.com> Message-ID: <226002CA-FC71-446C-8B73-A8517D27206C@multicasttech.com> Hello; On Apr 18, 2006, at 7:06 PM, Peter Sherbin wrote: >> So the carriers owe the content providers $M's/month ??? > > In the exact same fashion as cable providers owe studios. > >> Obviously you haven't head of P2P, or people hosting family oriented >> content. Not all traffic is download. > > Look again at the formula. If (Download - Upload) < 0, then your > bill equals 0. > Traffic uploaders (aka content providers) are good for the network > because: > Assumption 1. People access the Internet to download content > (and such downloaders are supposed to pay for satisfying that need). > In my home use, I send out about 10 x as much as I bring in. Does this mean that I can get a connection from you and you will pay me ? If so, please send me contract details. Regards Marshall Eubanks >> That billing model is not ready for use, and security or lack >> thereof has >> nothing to do with it. > > If security has nothing to do with the Internet then why does the > community spends > so much time and effort on it? > > Peter > > --- Tony Hain wrote: > >> Peter Sherbin wrote: >>> The Internet billing model is simple: >>> >>> (Download - Upload) * $/bit = Billed Amount >> >> So the carriers owe the content providers $M's/month ??? >> >>> >>> It is based on two assumptions: >>> 1. People access the Internet to download content >>> 2. Paying party controls their download activity >> >> Obviously you haven't head of P2P, or people hosting family oriented >> content. Not all traffic is download. >> >>> >>> If security becomes a prohibitive concern for the above then the >>> product >>> is just not >>> ready for use. >> >> That billing model is not ready for use, and security or lack >> thereof has >> nothing to do with it. >> >> Tony >> >> >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From randy at psg.com Wed Apr 19 00:15:21 2006 From: randy at psg.com (Randy Bush) Date: Tue, 18 Apr 2006 18:15:21 -1000 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] References: <20060418230654.41683.qmail@web54707.mail.yahoo.com> <226002CA-FC71-446C-8B73-A8517D27206C@multicasttech.com> Message-ID: <17477.47449.19583.317861@roam.psg.com> > In my home use, I send out about 10 x as much as I bring in. Does this > mean that I can get a connection from you and you will pay me ? If so, > please send me contract details. in many parts of the states, that's the way electricity works. i am sure google thinks it's a good model for the internet :-). randy From izumi at nic.ad.jp Wed Apr 19 01:46:17 2006 From: izumi at nic.ad.jp (Izumi Okutani) Date: Wed, 19 Apr 2006 14:46:17 +0900 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: References: Message-ID: <4445CEA9.3040606@nic.ad.jp> Hi Lea, [snip] >>The current issues in JP are two: >> >> + Some impact over the existing LIRs are noted, expecially in >> terms of expenses(1/2 LIRs face additional expenses of over >> US$85,000). > > > are these additional expenses one time costs? or do people feel there is > some ongoing cost to dealing with multiple assignment sizes even after > the supporting software is upgraded? The cost mentioned above is one time. There will also be on going cost in terms of address fragmentation and increased network complexity to support different sizes. These are not necessary cost in terms of money, but considered as damage to the existing service. How to address this problem is an issue for us, although I do also see that we shouldn't be overly swayed by the short-term impact in considering the long term future. > >> + Few LIRs LIRs expressed concerns that classless addressing will >> lose the benefit of IPv6 over IPv4. >> i.e, simplicity of network design and service specification >> I'd be happy to clarify if there is anything else I can explain. Thanks for taking an interest in our situation. izumi From hannigan at renesys.com Wed Apr 19 02:18:52 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Wed, 19 Apr 2006 02:18:52 -0400 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: References: Message-ID: <7.0.1.0.2.20060419014026.0221e550@renesys.com> At 12:25 PM 4/10/2006, Divins, David wrote: >Due to popular demand....Attempt number 3 at an accurate Subject :-) During the XVII meeting, I talked to the author of the residential privacy policy, David Divens, and Aaron Hughes, regarding their concerns over residential and business privacy. My suggestion to the AC (and proposers) regarding proposals would be a rewrite to accomplish the following: - eliminate differentiation between residential and business - designate /29's and smaller as private - reduction of NA postal codes to 3 characters - creating a confidential/undercover registration clause to allow LEA to mask registrations for investigative, intelligence, or other purposes as long as they identify these to ARIN staff AND ARIN is able to handle such information per FISA, Title III. CALEA, and other applicable regulations (IANAL). This follows a concept invoked by DMV's related to license plates. (and a memory jogging by Heather Skanks - thank you!) My recommendation is based on the following prefix distribution data that we have compiled based on whois data not older than 2 weeks. It shows that /29 is over 60% of all data and we would improve overall privacy by X factors. I think it is fair to say that the vast majority of residences are within /29, and I agree with Owen Delong that privacy is not an expectation for business whois data. This is more balanced than a complete masking of location data. I would like to hear what LEA's think of this, and I would be happy to consider adjustments on the confidential registration idea. Current applications of whois data include geo-location, which does not necessarily rely solely on whois data, but does use it for triangulation purposes. I think we would be surprised at the list of applications utilizing the postal code for this, and I am informing other geo-locators of this proposal and location of discussion so that they may participate if desired. MASK PFX 4 2 6 1 7 2 8 188 9 1 10 6 11 13 12 36 13 81 14 216 15 411 16 7287 17 681 18 1399 19 3170 20 6004 21 4794 22 10262 23 19743 24 120053 25 33036 26 38778 27 103976 28 137726 29 847640 (66% of all registrations) 30 184 31 3 Non-CIDR=11078 -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From owen at delong.com Wed Apr 19 02:58:08 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Apr 2006 23:58:08 -0700 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: <7.0.1.0.2.20060419014026.0221e550@renesys.com> References: <7.0.1.0.2.20060419014026.0221e550@renesys.com> Message-ID: <558ADEA0CA26FB92C328C6A6@odpwrbook.hq.netli.lan> --On April 19, 2006 2:18:52 AM -0400 Martin Hannigan wrote: > At 12:25 PM 4/10/2006, Divins, David wrote: >> Due to popular demand....Attempt number 3 at an accurate Subject :-) > > During the XVII meeting, I talked to the author of the residential > privacy policy, David Divens, and Aaron Hughes, regarding their > concerns over residential and business privacy. > > My suggestion to the AC (and proposers) regarding > proposals would be a rewrite to accomplish the following: > > - eliminate differentiation between residential and business I strongly oppose this provision. There is no reason to remove address accountability from business orgs. > - designate /29's and smaller as private Since smaller than /29s are already non-swip entities, that's de facto already for smaller prefixes. I would rather not move the boundary left to /29 since it would obscure so many current assignments. > - reduction of NA postal codes to 3 characters I'd rather see 5 in terms of US ZIP. 3 is the bulk mail center. 5 is the serving post office. In Canada, 3 seems to provide similar granularity. > - creating a confidential/undercover registration clause to allow > LEA to mask registrations for investigative, intelligence, > or other purposes as long as they identify these to ARIN > staff AND ARIN is able to handle such information per FISA, Title III. > CALEA, and other applicable regulations (IANAL). This > follows a concept invoked by DMV's related to license plates. > (and a memory jogging by Heather Skanks - thank you!) Sorry, I just don't see a need for this. The black hats have plenty of IP space from DoD and lots of other sources and they're plaing on their own networks anyway. This just provides another layer of headache to ISPs and doesn't benefit the community in any way. Convenience at concealment for government ops. is the last thing I want to see expanded under the current administration. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jeroen at unfix.org Wed Apr 19 03:28:30 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 19 Apr 2006 09:28:30 +0200 Subject: [ppml] The Pope gets IPv6 PA space (not PI :) Message-ID: <1145431710.17463.2.camel@firenze.zurich.ibm.com> inet6num: 2a01:b8::/32 netname: VA-VATICAN-20060418 descr: Holy See - Vatican City State country: VA So now that IPv6 is officially blessed go deploy it :) Greets, Jeroen Reply-To explicitly set to myself so that people don't reply to this silly post to all the lists... override to the one you like if you want -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From Michael.Dillon at btradianz.com Wed Apr 19 03:55:23 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 19 Apr 2006 08:55:23 +0100 Subject: [ppml] New WHOIS policy approved Message-ID: ICANN has approved a new whois policy http://www.circleid.com/posts/historic_vote_on_whois_reformers_win/ The purpose is defined as: The purpose of the gTLD Whois service is to provide information sufficient to contact a responsible party for a particular gTLD domain name who can resolve, or reliably pass on data to a party who can resolve, issues related to the configuration of the records associated with the domain name within a DNS nameserver. Compare that to item 3 in the proposal 2004-4 http://www.arin.net/policy/proposals/2004_4.html ------------------------------------------------------- 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 From owen at delong.com Wed Apr 19 04:33:09 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Apr 2006 01:33:09 -0700 Subject: [ppml] New WHOIS policy approved In-Reply-To: References: Message-ID: Why? There is not much of a relationship between the ICANN gTLD whois and the LIR whois data and I see no reason that the policies should somehow be synchronized. Domains and IPs are different and serve different purposes. Owen --On April 19, 2006 8:55:23 AM +0100 Michael.Dillon at btradianz.com wrote: > ICANN has approved a new whois policy > http://www.circleid.com/posts/historic_vote_on_whois_reformers_win/ > > The purpose is defined as: > The purpose of the gTLD Whois service is to provide information > sufficient to contact a responsible party for a particular gTLD > domain name who can resolve, or reliably pass on data to a party > who can resolve, issues related to the configuration of the records > associated with the domain name within a DNS nameserver. > > Compare that to item 3 in the proposal 2004-4 > http://www.arin.net/policy/proposals/2004_4.html > > ------------------------------------------------------- > 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 > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From sleibrand at internap.com Wed Apr 19 07:51:20 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 19 Apr 2006 07:51:20 -0400 (EDT) Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: <7.0.1.0.2.20060419014026.0221e550@renesys.com> References: <7.0.1.0.2.20060419014026.0221e550@renesys.com> Message-ID: On 04/19/06 at 2:18am -0400, Martin Hannigan wrote: > My suggestion to the AC (and proposers) regarding > proposals would be a rewrite to accomplish the following: > > - eliminate differentiation between residential and business So this would allow ISPs to omit street address information for all registrants, regardless of size? That strikes me as excessive. Also, currently the differentiation between residential and business allows ISPs to put "Private Residence" in the name field for residential customers. Would you disallow that, or allow something similar for "Private Business"? IMO either would be undesirable. > - designate /29's and smaller as private If you re-worded this to make SWIPs for /29's optional, I wouldn't oppose this provision. I don't like designating them private, as that implies you MUST NOT (or at least SHOULD NOT) SWIP them. > - reduction of NA postal codes to 3 characters Again, there's an implication here that postal codes MUST NOT be more than 3 characters, which IMO is a bad idea. I'm OK with *allowing* ISPs to submit SWIPs with City, State/Province, and 3-character ZIP/postal code, although that introduces an unfairness between US ZIP codes and Canadian Postal Codes, since a 3-digit ZIP code is much less specific than a 3-character Postal Code. [No comment on LEA stuff.] > My recommendation is based on the following prefix distribution > data that we have compiled based on whois data not older than > 2 weeks. It shows that /29 is over 60% of all data and we would > improve overall privacy by X factors. I think it is fair to say that > the vast majority of residences are within /29, and I agree with Owen Delong > that privacy is not an expectation for business whois data. If you agree with this, then do you in fact intend to allow street addresses to be masked for all business SWIPs? It seems to me the first bullet point above is completely at odds with this statement. -Scott From Michael.Dillon at btradianz.com Wed Apr 19 07:52:17 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 19 Apr 2006 12:52:17 +0100 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <99782.1145378987@sa.vix.com> Message-ID: > the current settlement regime locks new providers out of the > market, to the detriment of end-users everywhere. go ahead, > tell me how you'd spend $1B to join the DFZ with pure SFP in > 10 years, and then tell me how you'd ever make that money back > at the current/declining transit and on-net prices now seen. You show me why it is worth $1B to join the DFZ. The point is still the same, for all its complexities, Internet peering is nowhere near as complex as telephony accounting and settlements which cost some companies as much as 70% of their expenses back in the early 90s. The Internet is as much about flat rates as it is about packet switching. --Michael Dillon From Michael.Dillon at btradianz.com Wed Apr 19 08:00:49 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 19 Apr 2006 13:00:49 +0100 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <20060418221449.99759.qmail@web54704.mail.yahoo.com> Message-ID: > The Internet billing model is simple: > > (Download - Upload) * $/bit = Billed Amount This is simply not true. I am not aware of any ISP that charges for service in this way. > It is based on two assumptions: > 1. People access the Internet to download content > 2. Paying party controls their download activity This is also not true. People access the Internet for many reasons, some of which equate to uploading content. In a common download transaction, both the downloader and the content provider pay for their Internet service. > If security becomes a prohibitive concern for the above then the > product is just not > ready for use. The Internet has been running this way for over 10 years. --Michael Dillon From Michael.Dillon at btradianz.com Wed Apr 19 08:02:21 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 19 Apr 2006 13:02:21 +0100 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <20060418225310.74464.qmail@web54706.mail.yahoo.com> Message-ID: > As a financially conscious ISP I want volume based pricing as the > major marketing, > product development and ROI tool. Read Odlyzko's papers to see why you will never get pure volume based pricing. http://www.dtc.umn.edu/~odlyzko/doc/networks.html --Michael Dillon From Michael.Dillon at btradianz.com Wed Apr 19 08:11:53 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 19 Apr 2006 13:11:53 +0100 Subject: [ppml] New WHOIS policy approved In-Reply-To: Message-ID: > Why? There is not much of a relationship between the ICANN gTLD > whois and the LIR whois data and I see no reason that the policies > should somehow be synchronized. Domains and IPs are different > and serve different purposes. The gTLD whois and LIR whois are twin sisters born of the same mother (ARPANET). They only diverged when the Internic was split into separate RIRs and gTLD registries. As fraternal twin sisters, they share various genetic similarities and have suffered similar perversions at the hands of commercial interests. Now, the ICANN folks are bringing their whois policies in from the cold, and closer to their original intention. I think it is highly appropriate for ARIN to do something similar and expect to see a policy proposal on this in a few months from now. Note, that Domains and IPs do share some characteristics. They are both delegated to an official holder. They are both associated with Internet endpoints. They are both trackable within the network infrastructure. I agree that the policies should not be mindlessly synchronized however, I also feel that the policies need to be made completely clear and also be within ARIN's scope of activity. --Michael Dillon From pesherb at yahoo.com Wed Apr 19 09:28:47 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Wed, 19 Apr 2006 06:28:47 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] In-Reply-To: <226002CA-FC71-446C-8B73-A8517D27206C@multicasttech.com> Message-ID: <20060419132847.93099.qmail@web54703.mail.yahoo.com> > In my home use, I send out about 10 x as much as I bring in. Does > this mean that > I can get a connection from you and you will pay me ? That is correct. ISP would charge those on their network downloading what you send out. To do that ISP needs to count data flows by user. Payout to you from ISP depends on the volume and may take different shapes, e.g. volume credit towards future downloads. The bottom line is a downloader pays to an uploader for content. There is also a flat rate to cover provider costs (same as flat monthly rate for a regular phone wireline). Peter --- Marshall Eubanks wrote: > Hello; > > On Apr 18, 2006, at 7:06 PM, Peter Sherbin wrote: > > >> So the carriers owe the content providers $M's/month ??? > > > > In the exact same fashion as cable providers owe studios. > > > >> Obviously you haven't head of P2P, or people hosting family oriented > >> content. Not all traffic is download. > > > > Look again at the formula. If (Download - Upload) < 0, then your > > bill equals 0. > > Traffic uploaders (aka content providers) are good for the network > > because: > > Assumption 1. People access the Internet to download content > > (and such downloaders are supposed to pay for satisfying that need). > > > > In my home use, I send out about 10 x as much as I bring in. Does > this mean that > I can get a connection from you and you will pay me ? If so, please > send me contract details. > > Regards > Marshall Eubanks > > >> That billing model is not ready for use, and security or lack > >> thereof has > >> nothing to do with it. > > > > If security has nothing to do with the Internet then why does the > > community spends > > so much time and effort on it? > > > > Peter > > > > --- Tony Hain wrote: > > > >> Peter Sherbin wrote: > >>> The Internet billing model is simple: > >>> > >>> (Download - Upload) * $/bit = Billed Amount > >> > >> So the carriers owe the content providers $M's/month ??? > >> > >>> > >>> It is based on two assumptions: > >>> 1. People access the Internet to download content > >>> 2. Paying party controls their download activity > >> > >> Obviously you haven't head of P2P, or people hosting family oriented > >> content. Not all traffic is download. > >> > >>> > >>> If security becomes a prohibitive concern for the above then the > >>> product > >>> is just not > >>> ready for use. > >> > >> That billing model is not ready for use, and security or lack > >> thereof has > >> nothing to do with it. > >> > >> Tony > >> > >> > >> > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dsd at servervault.com Wed Apr 19 09:48:20 2006 From: dsd at servervault.com (Divins, David) Date: Wed, 19 Apr 2006 09:48:20 -0400 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois Message-ID: >I strongly oppose this provision. There is no reason to remove address accountability from business orgs If Whois contains accurate contact/abuse info, how is this obscuring accountability? If there is abuse report it to the contact. A responsible ISP will handle that request. If the complaint is not handled to your satisfaction-- block the ISP at the FW level like many do to APNIC providers. Also, you are assuming these reassignments are being used for transit services, what about content providing. There is often little to no initiation from content provider based reassignments. -dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 From hannigan at renesys.com Wed Apr 19 09:50:15 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Wed, 19 Apr 2006 09:50:15 -0400 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: <558ADEA0CA26FB92C328C6A6@odpwrbook.hq.netli.lan> References: <7.0.1.0.2.20060419014026.0221e550@renesys.com> <558ADEA0CA26FB92C328C6A6@odpwrbook.hq.netli.lan> Message-ID: <7.0.1.0.2.20060419094320.022d2d38@renesys.com> At 02:58 AM 4/19/2006, Owen DeLong wrote: >Content-Type: text/plain; charset=us-ascii; format=flowed >Content-Transfer-Encoding: quoted-printable >Content-Disposition: inline > > >*** PGP Signature Status: unknown >*** Signer: Unknown, Key ID = 0x0FE2AA3D >*** Signed: 4/19/2006 2:58:09 AM >*** Verified: 4/19/2006 9:43:13 AM >*** BEGIN PGP VERIFIED MESSAGE *** > > > >--On April 19, 2006 2:18:52 AM -0400 Martin Hannigan = > >wrote: > > > At 12:25 PM 4/10/2006, Divins, David wrote: > >> Due to popular demand....Attempt number 3 at an accurate Subject :-) > > > > During the XVII meeting, I talked to the author of the residential > > privacy policy, David Divens, and Aaron Hughes, regarding their > > concerns over residential and business privacy. > > > > My suggestion to the AC (and proposers) regarding > > proposals would be a rewrite to accomplish the following: > > > > - eliminate differentiation between residential and business > >I strongly oppose this provision. There is no reason to remove >address accountability from business orgs. How would you do this? [ snip ] > > - creating a confidential/undercover registration clause to allow > > LEA to mask registrations for investigative, intelligence, > > or other purposes as long as they identify these to ARIN > > staff AND ARIN is able to handle such information per FISA, Title III. > > CALEA, and other applicable regulations (IANAL). This > > follows a concept invoked by DMV's related to license plates. > > (and a memory jogging by Heather Skanks - thank you!) > >Sorry, I just don't see a need for this. The black hats have plenty >of IP space from DoD and lots of other sources and they're plaing >on their own networks anyway. This just provides another layer of >headache to ISPs and doesn't benefit the community in any way. >Convenience at concealment for government ops. is the last thing >I want to see expanded under the current administration. I meant to say they would inform their provider. Providers who have customers who have such a need are already set up to function this way and would merely be a workflow issue for them, if not simply legitimizing the inaccuracies they are already sending. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From pesherb at yahoo.com Wed Apr 19 10:19:55 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Wed, 19 Apr 2006 07:19:55 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: Message-ID: <20060419141955.47361.qmail@web54714.mail.yahoo.com> > > The Internet billing model is simple: > > > > (Download - Upload) * $/bit = Billed Amount > > This is simply not true. I am not aware of any ISP > that charges for service in this way. You are correct. ISP do not charge that way even so they should. > > It is based on two assumptions: > > 1. People access the Internet to download content > > 2. Paying party controls their download activity > > This is also not true. People access the Internet for > many reasons, some of which equate to uploading content. > In a common download transaction, both the downloader and > the content provider pay for their Internet service. You are welcome to upload an unlimited quantity of anything. The transaction will not happen so unless there is a downloading party. (Flat) access fee is needed to cover facilities that connect transactors. > > If security becomes a prohibitive concern for the above then the > > product is just not > > ready for use. > > The Internet has been running this way for over 10 years. Which proves that the security issue is not a prohibitive concern. Peter > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From pesherb at yahoo.com Wed Apr 19 10:42:28 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Wed, 19 Apr 2006 07:42:28 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: Message-ID: <20060419144228.57513.qmail@web54713.mail.yahoo.com> "Even tiny charges based on utilization decrease usage substantially." (Internet pricing and the history of communications, A. M. Odlyzko.) Here is a practical example. This winter my natural gas price has increased by 100% with hardly any impact on usage. The above comparison assumes that whatever runs through the Internet pipes is a commodity. Peter --- Michael.Dillon at btradianz.com wrote: > > As a financially conscious ISP I want volume based pricing as the > > major marketing, > > product development and ROI tool. > > Read Odlyzko's papers to see why you will never get > pure volume based pricing. > http://www.dtc.umn.edu/~odlyzko/doc/networks.html > > --Michael Dillon > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From william at elan.net Wed Apr 19 11:01:30 2006 From: william at elan.net (william(at)elan.net) Date: Wed, 19 Apr 2006 08:01:30 -0700 (PDT) Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: <7.0.1.0.2.20060419014026.0221e550@renesys.com> References: <7.0.1.0.2.20060419014026.0221e550@renesys.com> Message-ID: On Wed, 19 Apr 2006, Martin Hannigan wrote: > At 12:25 PM 4/10/2006, Divins, David wrote: >> Due to popular demand....Attempt number 3 at an accurate Subject :-) > > During the XVII meeting, I talked to the author of the residential > privacy policy, David Divens, and Aaron Hughes, regarding their > concerns over residential and business privacy. > > My suggestion to the AC (and proposers) regarding > proposals would be a rewrite to accomplish the following: > > - eliminate differentiation between residential and business > - designate /29's and smaller as private Actually I'm in favor of making /26 as minimum block required for public whois registration. The data below confirms that this is good boundary. I suggested similar before too... > - reduction of NA postal codes to 3 characters That is also fine. 3 characters is enough for US postal codes to identify geographic area. > - creating a confidential/undercover registration clause to allow > LEA to mask registrations for investigative, intelligence, > or other purposes as long as they identify these to ARIN > staff AND ARIN is able to handle such information per FISA, Title III. > CALEA, and other applicable regulations (IANAL). This > follows a concept invoked by DMV's related to license plates. > (and a memory jogging by Heather Skanks - thank you!) There is too much complexity that you will impose on ARIN if you do it this way. I don't think ARIN is using sub-/24 allocations much for registration purposes so I think just increasing the boundary will be good enough. > My recommendation is based on the following prefix distribution > data that we have compiled based on whois data not older than > 2 weeks. It shows that /29 is over 60% of all data and we would > improve overall privacy by X factors. I think it is fair to say that > the vast majority of residences are within /29, and I agree with Owen Delong > that privacy is not an expectation for business whois data. > > This is more balanced than a complete masking of location data. > I would like to hear what LEA's think of this, and I would be happy to > consider adjustments on the confidential registration idea. > > Current applications of whois data include geo-location, which does > not necessarily rely solely on whois data, but does use it for triangulation > purposes. I think we would be surprised at the list of applications utilizing > the postal code for this, and I am informing other geo-locators of this > proposal and location of discussion so that they may participate if desired. > > MASK PFX > > 4 2 > 6 1 > 7 2 > 8 188 > 9 1 > 10 6 > 11 13 > 12 36 > 13 81 > 14 216 > 15 411 > 16 7287 > 17 681 > 18 1399 > 19 3170 > 20 6004 > 21 4794 > 22 10262 > 23 19743 > 24 120053 > 25 33036 > 26 38778 > 27 103976 > 28 137726 > 29 847640 (66% of all registrations) > 30 184 > 31 3 > > Non-CIDR=11078 > > -- > 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 Lee.Howard at stanleyassociates.com Wed Apr 19 11:12:05 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 19 Apr 2006 11:12:05 -0400 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB401D649B6@CL-S-EX-1.stanleyassociates.com> Can anyone relate this thread back to a discussion of any current or future policy proposal? Thanks, Lee > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Peter Sherbin > Sent: Wednesday, April 19, 2006 10:42 AM > To: Michael.Dillon at btradianz.com; ppml at arin.net > Subject: Re: [ppml] [narten at us.ibm.com: PI addressing in IPv6 > advances inARIN] > > "Even tiny charges based on utilization decrease usage substantially." > (Internet pricing and the history of communications, A. M. Odlyzko.) > > Here is a practical example. This winter my natural gas price > has increased by 100% > with hardly any impact on usage. > > The above comparison assumes that whatever runs through the > Internet pipes is a > commodity. > > Peter > > > --- Michael.Dillon at btradianz.com wrote: > > > > As a financially conscious ISP I want volume based pricing as the > > > major marketing, > > > product development and ROI tool. > > > > Read Odlyzko's papers to see why you will never get > > pure volume based pricing. > > http://www.dtc.umn.edu/~odlyzko/doc/networks.html > > > > --Michael Dillon > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From hannigan at renesys.com Wed Apr 19 13:19:29 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Wed, 19 Apr 2006 13:19:29 -0400 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: References: <7.0.1.0.2.20060419014026.0221e550@renesys.com> Message-ID: <7.0.1.0.2.20060419130536.0228fbc0@renesys.com> At 11:01 AM 4/19/2006, william(at)elan.net wrote: >On Wed, 19 Apr 2006, Martin Hannigan wrote: > >>At 12:25 PM 4/10/2006, Divins, David wrote: >>>Due to popular demand....Attempt number 3 at an accurate Subject :-) [ SNIP ] >>- creating a confidential/undercover registration clause to allow >> LEA to mask registrations for investigative, intelligence, >> or other purposes as long as they identify these to ARIN >> staff AND ARIN is able to handle such information per FISA, Title III. >> CALEA, and other applicable regulations (IANAL). This >> follows a concept invoked by DMV's related to license plates. >> (and a memory jogging by Heather Skanks - thank you!) > >There is too much complexity that you will impose on ARIN if you do it >this way. Yes, I meant to say the LIR? All we would be doing here is allowing them to continue to mask data, but be required to base it on a policy. I think this is just an administrative approval of what is already taking place. >I don't think ARIN is using sub-/24 allocations much for >registration purposes so I think just increasing the boundary will >be good enough. > I'm split to be honest. If no change occurs, I'm perfectly content. The proposal was interesting, but unbalanced, IMHO. If I get a chance this week, I'm going to hand sift through the whois data and see if I can key in on business vs. residential saturation in /29 to try and answer Owens concern. From owen at delong.com Wed Apr 19 15:26:32 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Apr 2006 12:26:32 -0700 Subject: [ppml] New WHOIS policy approved In-Reply-To: References: Message-ID: --On April 19, 2006 1:11:53 PM +0100 Michael.Dillon at btradianz.com wrote: >> Why? There is not much of a relationship between the ICANN gTLD >> whois and the LIR whois data and I see no reason that the policies >> should somehow be synchronized. Domains and IPs are different >> and serve different purposes. > > The gTLD whois and LIR whois are twin sisters born of the > same mother (ARPANET). They only diverged when the Internic > was split into separate RIRs and gTLD registries. As fraternal > twin sisters, they share various genetic similarities and > have suffered similar perversions at the hands of commercial > interests. > True, but, no longer particularly relevant to the practice and purpose of either. Even back in the day of SRI InterNIC, the use and content of IP registration whois data and Domain whois data was different. I would say they are sisters, but, I'm not so sure they're twins rather than step sisters. I think they had different fathers. > Now, the ICANN folks are bringing their whois policies in > from the cold, and closer to their original intention. > I think it is highly appropriate for ARIN to do something > similar and expect to see a policy proposal on this in a few > months from now. > I guess we can agree to disagree on this. I think that the amount of indirection and misdirection allowed by ICANNs new domain policy is a bad idea and I'd hate to see it added to ARIN whois policy, no matter how convenient it is for BT. > Note, that Domains and IPs do share some characteristics. > They are both delegated to an official holder. They are both > associated with Internet endpoints. They are both trackable > within the network infrastructure. > Domains are not associated with internet endpoints in any way other than their ability to be mapped to an IP address. Domains are loosely coupled with IP addresses. The only use of a domain is to provide a handle for lookup in a directory. IP addresses, OTOH, are used for traffic delivery and specify a particular point on the internet (notwithstanding anycast and multicast for the moment). Since domains are not reliably mapped in a bidirectional manner, domain whois data is only minimally useful in dealing with a real time security event and as such, I'm far less concerned about it having useful content. > I agree that the policies should not be mindlessly synchronized > however, I also feel that the policies need to be made completely > clear and also be within ARIN's scope of activity. > I don't think that clarifying whois policy would be a bad thing at all. I just don't want to see that clarification include the kind of wiggle room just offered to spammers in the new ICANN policy. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Wed Apr 19 15:28:53 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Apr 2006 12:28:53 -0700 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] In-Reply-To: <20060419132847.93099.qmail@web54703.mail.yahoo.com> References: <20060419132847.93099.qmail@web54703.mail.yahoo.com> Message-ID: <74A5A4A85714B648D9129038@imac-en0.delong.sj.ca.us> What if there is no downloader? It's very trivial to generate lots of outbound traffic to look like "upload" without anyone on the other end caring about what arrives. So... Under your model, ISP pays me to clog up his network with packets destined to non-existant sites and bills who, exactly to cover these costs? Owen --On April 19, 2006 6:28:47 AM -0700 Peter Sherbin wrote: >> In my home use, I send out about 10 x as much as I bring in. Does >> this mean that >> I can get a connection from you and you will pay me ? > > That is correct. ISP would charge those on their network downloading what > you send out. To do that ISP needs to count data flows by user. > Payout to you from ISP depends on the volume and may take different > shapes, e.g. volume credit towards future downloads. > The bottom line is a downloader pays to an uploader for content. There is > also a flat rate to cover provider costs (same as flat monthly rate for a > regular phone wireline). > > Peter > > --- Marshall Eubanks wrote: > >> Hello; >> >> On Apr 18, 2006, at 7:06 PM, Peter Sherbin wrote: >> >> >> So the carriers owe the content providers $M's/month ??? >> > >> > In the exact same fashion as cable providers owe studios. >> > >> >> Obviously you haven't head of P2P, or people hosting family oriented >> >> content. Not all traffic is download. >> > >> > Look again at the formula. If (Download - Upload) < 0, then your >> > bill equals 0. >> > Traffic uploaders (aka content providers) are good for the network >> > because: >> > Assumption 1. People access the Internet to download content >> > (and such downloaders are supposed to pay for satisfying that need). >> > >> >> In my home use, I send out about 10 x as much as I bring in. Does >> this mean that >> I can get a connection from you and you will pay me ? If so, please >> send me contract details. >> >> Regards >> Marshall Eubanks >> >> >> That billing model is not ready for use, and security or lack >> >> thereof has >> >> nothing to do with it. >> > >> > If security has nothing to do with the Internet then why does the >> > community spends >> > so much time and effort on it? >> > >> > Peter >> > >> > --- Tony Hain wrote: >> > >> >> Peter Sherbin wrote: >> >>> The Internet billing model is simple: >> >>> >> >>> (Download - Upload) * $/bit = Billed Amount >> >> >> >> So the carriers owe the content providers $M's/month ??? >> >> >> >>> >> >>> It is based on two assumptions: >> >>> 1. People access the Internet to download content >> >>> 2. Paying party controls their download activity >> >> >> >> Obviously you haven't head of P2P, or people hosting family oriented >> >> content. Not all traffic is download. >> >> >> >>> >> >>> If security becomes a prohibitive concern for the above then the >> >>> product >> >>> is just not >> >>> ready for use. >> >> >> >> That billing model is not ready for use, and security or lack >> >> thereof has >> >> nothing to do with it. >> >> >> >> Tony >> >> >> >> >> >> >> > >> > >> > __________________________________________________ >> > Do You Yahoo!? >> > Tired of spam? Yahoo! Mail has the best spam protection around >> > http://mail.yahoo.com >> > _______________________________________________ >> > PPML mailing list >> > PPML at arin.net >> > http://lists.arin.net/mailman/listinfo/ppml >> >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Wed Apr 19 15:31:15 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Apr 2006 12:31:15 -0700 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: References: Message-ID: --On April 19, 2006 9:48:20 AM -0400 "Divins, David" wrote: >> I strongly oppose this provision. There is no reason to remove address > accountability from business orgs > > If Whois contains accurate contact/abuse info, how is this obscuring > accountability? If there is abuse report it to the contact. A > responsible ISP will handle that request. If the complaint is not > handled to your satisfaction-- block the ISP at the FW level like many > do to APNIC providers. Also, you are assuming these reassignments are > being used for transit services, what about content providing. There is > often little to no initiation from content provider based reassignments. > The large number of IRRESPONSIBLE ISPs are the concern here. There's simply no reason that a business is, in my opinion, entitled to anonymity of their IP addresses. Unless the ISP has power of attorney to accept process service of my law suit, the business should have to be listed by address so I know where to send the process server. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From pesherb at yahoo.com Wed Apr 19 15:36:25 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Wed, 19 Apr 2006 12:36:25 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] In-Reply-To: <74A5A4A85714B648D9129038@imac-en0.delong.sj.ca.us> Message-ID: <20060419193625.28263.qmail@web54707.mail.yahoo.com> > So... Under your model, ISP pays me to clog up his network with packets > destined > to non-existant sites and bills who, exactly to cover these costs? In this case ISP would (as they should) treat such activity as DOS attack and penalize you for the abuse all the way up to cancelling the service. Again it boils down to the traffic counting / tracking by each customer. Thx, Peter --- Owen DeLong wrote: > What if there is no downloader? It's very trivial to generate lots of > outbound > traffic to look like "upload" without anyone on the other end caring about > what arrives. > > So... Under your model, ISP pays me to clog up his network with packets > destined > to non-existant sites and bills who, exactly to cover these costs? > > Owen > > > --On April 19, 2006 6:28:47 AM -0700 Peter Sherbin > wrote: > > >> In my home use, I send out about 10 x as much as I bring in. Does > >> this mean that > >> I can get a connection from you and you will pay me ? > > > > That is correct. ISP would charge those on their network downloading what > > you send out. To do that ISP needs to count data flows by user. > > Payout to you from ISP depends on the volume and may take different > > shapes, e.g. volume credit towards future downloads. > > The bottom line is a downloader pays to an uploader for content. There is > > also a flat rate to cover provider costs (same as flat monthly rate for a > > regular phone wireline). > > > > Peter > > > > --- Marshall Eubanks wrote: > > > >> Hello; > >> > >> On Apr 18, 2006, at 7:06 PM, Peter Sherbin wrote: > >> > >> >> So the carriers owe the content providers $M's/month ??? > >> > > >> > In the exact same fashion as cable providers owe studios. > >> > > >> >> Obviously you haven't head of P2P, or people hosting family oriented > >> >> content. Not all traffic is download. > >> > > >> > Look again at the formula. If (Download - Upload) < 0, then your > >> > bill equals 0. > >> > Traffic uploaders (aka content providers) are good for the network > >> > because: > >> > Assumption 1. People access the Internet to download content > >> > (and such downloaders are supposed to pay for satisfying that need). > >> > > >> > >> In my home use, I send out about 10 x as much as I bring in. Does > >> this mean that > >> I can get a connection from you and you will pay me ? If so, please > >> send me contract details. > >> > >> Regards > >> Marshall Eubanks > >> > >> >> That billing model is not ready for use, and security or lack > >> >> thereof has > >> >> nothing to do with it. > >> > > >> > If security has nothing to do with the Internet then why does the > >> > community spends > >> > so much time and effort on it? > >> > > >> > Peter > >> > > >> > --- Tony Hain wrote: > >> > > >> >> Peter Sherbin wrote: > >> >>> The Internet billing model is simple: > >> >>> > >> >>> (Download - Upload) * $/bit = Billed Amount > >> >> > >> >> So the carriers owe the content providers $M's/month ??? > >> >> > >> >>> > >> >>> It is based on two assumptions: > >> >>> 1. People access the Internet to download content > >> >>> 2. Paying party controls their download activity > >> >> > >> >> Obviously you haven't head of P2P, or people hosting family oriented > >> >> content. Not all traffic is download. > >> >> > >> >>> > >> >>> If security becomes a prohibitive concern for the above then the > >> >>> product > >> >>> is just not > >> >>> ready for use. > >> >> > >> >> That billing model is not ready for use, and security or lack > >> >> thereof has > >> >> nothing to do with it. > >> >> > >> >> Tony > >> >> > >> >> > >> >> > >> > > >> > > >> > __________________________________________________ > >> > Do You Yahoo!? > >> > Tired of spam? Yahoo! Mail has the best spam protection around > >> > http://mail.yahoo.com > >> > _______________________________________________ > >> > PPML mailing list > >> > PPML at arin.net > >> > http://lists.arin.net/mailman/listinfo/ppml > >> > >> > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > -- > If it wasn't crypto-signed, it probably didn't come from me. > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From Ed.Lewis at neustar.biz Wed Apr 19 15:36:44 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 19 Apr 2006 15:36:44 -0400 Subject: [ppml] Mutating RSA -- Policy Proposal In-Reply-To: <5EDBECF0BD058B60E6E8C681@imac-en0.delong.sj.ca.us> References: <5EDBECF0BD058B60E6E8C681@imac-en0.delong.sj.ca.us> Message-ID: Thanks, Owen, I like the effort. (Hadn't thought of proposing to add a new section to the NPRM). If there's a need for a count of people interested in this, add me. I have some questions on the content. Is the RSA the same for everyone? I had assumed that once signed, the RSA was between the registrant and ARIN, and that modifications to one RSA only involved the one registrant. I was surprised to see that changes would go to PPML, I would have thought to the registrant involved. Or plural. I don't know how to read 11.1b. Do you mean that BoT, under advice of council, has authority to veto? I'm just unclear what it means to "have the authority" ... "if doing so at the advice of council." (See http://lists.arin.net/pipermail/ppml/2006-April/005305.html for the proposal.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From owen at delong.com Wed Apr 19 15:59:56 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Apr 2006 12:59:56 -0700 Subject: [ppml] Mutating RSA -- Policy Proposal In-Reply-To: References: <5EDBECF0BD058B60E6E8C681@imac-en0.delong.sj.ca.us> Message-ID: <9C3E04364B6E5F622026CCC1@imac-en0.delong.sj.ca.us> --On April 19, 2006 3:36:44 PM -0400 Edward Lewis wrote: > Thanks, Owen, I like the effort. (Hadn't thought of proposing to add a > new section to the NPRM). If there's a need for a count of people > interested in this, add me. > > I have some questions on the content. > > Is the RSA the same for everyone? I had assumed that once signed, the > RSA was between the registrant and ARIN, and that modifications to one > RSA only involved the one registrant. I was surprised to see that > changes would go to PPML, I would have thought to the registrant > involved. Or plural. > As far as I know, revisions to the RSA are global. > I don't know how to read 11.1b. Do you mean that BoT, under advice of > council, has authority to veto? I'm just unclear what it means to "have > the authority" ... "if doing so at the advice of council." > Yes. It is intended to allow the BoT to veto, but, only in such instance as ARIN legal counsel (council is actually a typo) feels that the provision would pose a legal risk of some form to ARIN. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From alh-ietf at tndh.net Wed Apr 19 16:25:59 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 19 Apr 2006 13:25:59 -0700 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] In-Reply-To: <74A5A4A85714B648D9129038@imac-en0.delong.sj.ca.us> Message-ID: <08b601c663ef$785de1f0$d447190a@tndh.net> Owen DeLong wrote: > > What if there is no downloader? It's very trivial to generate lots of > outbound > traffic to look like "upload" without anyone on the other end caring about > what arrives. > > So... Under your model, ISP pays me to clog up his network with packets > destined > to non-existant sites and bills who, exactly to cover these costs? > I think you missed the point. Sending to non-existent sites will only lead the provider back to you. Instead we should all generate continuous low-level streams to Peter, who will then graciously pay for our connections because he is receiving so much valuable content. ;) Tony From pesherb at yahoo.com Wed Apr 19 16:57:02 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Wed, 19 Apr 2006 13:57:02 -0700 (PDT) Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] In-Reply-To: <08b601c663ef$785de1f0$d447190a@tndh.net> Message-ID: <20060419205702.88548.qmail@web54703.mail.yahoo.com> > low-level streams to Peter, who will then graciously pay for our connections > because he is receiving so much valuable content. ;) 1. Bits from Yahoo mail server to my PC are minimal 2. Spam goes to a trash bin unopened Remember Assumption 2. Downloader controls the session. Peter --- Tony Hain wrote: > Owen DeLong wrote: > > > > What if there is no downloader? It's very trivial to generate lots of > > outbound > > traffic to look like "upload" without anyone on the other end caring about > > what arrives. > > > > So... Under your model, ISP pays me to clog up his network with packets > > destined > > to non-existant sites and bills who, exactly to cover these costs? > > > I think you missed the point. Sending to non-existent sites will only lead > the provider back to you. Instead we should all generate continuous > low-level streams to Peter, who will then graciously pay for our connections > because he is receiving so much valuable content. ;) > > Tony > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dsd at servervault.com Wed Apr 19 17:08:55 2006 From: dsd at servervault.com (Divins, David) Date: Wed, 19 Apr 2006 17:08:55 -0400 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois Message-ID: Do irresponsible ISPs SWIP correctly to begin with? It seems to me that any policy movement here is to help responsible parties comply. The irresponsible ones don't care, they do what they want and that's that. The reality is a customer that I am concerned about using SWIP for will never be seen un-obfuscated in whois--period, under any policy construct. That said; what I am looking for is a way as a responsible party to have a mechanism to deal with these "corner cases" in an appropriate manner. This may be a wacky case for a lot of people but it is a majority of my customers. I do not have all the answers but I believe there is something that can be done in this space. -dsd -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, April 19, 2006 3:31 PM To: Divins, David; Martin Hannigan; ppml at arin.net Subject: RE: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois --On April 19, 2006 9:48:20 AM -0400 "Divins, David" wrote: >> I strongly oppose this provision. There is no reason to remove address > accountability from business orgs > > If Whois contains accurate contact/abuse info, how is this obscuring > accountability? If there is abuse report it to the contact. A > responsible ISP will handle that request. If the complaint is not > handled to your satisfaction-- block the ISP at the FW level like many > do to APNIC providers. Also, you are assuming these reassignments are > being used for transit services, what about content providing. There is > often little to no initiation from content provider based reassignments. > The large number of IRRESPONSIBLE ISPs are the concern here. There's simply no reason that a business is, in my opinion, entitled to anonymity of their IP addresses. Unless the ISP has power of attorney to accept process service of my law suit, the business should have to be listed by address so I know where to send the process server. Owen -- If it wasn't crypto-signed, it probably didn't come from me. From dsd at servervault.com Wed Apr 19 17:10:13 2006 From: dsd at servervault.com (Divins, David) Date: Wed, 19 Apr 2006 17:10:13 -0400 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advancesinARIN] Message-ID: I have to believe we have officially gone way off topic. -dsd -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Peter Sherbin Sent: Wednesday, April 19, 2006 4:57 PM To: Tony Hain; ppml at arin.net Subject: Re: [ppml] [narten at us.ibm.com: PI addressing in IPv6 advancesinARIN] > low-level streams to Peter, who will then graciously pay for our connections > because he is receiving so much valuable content. ;) 1. Bits from Yahoo mail server to my PC are minimal 2. Spam goes to a trash bin unopened Remember Assumption 2. Downloader controls the session. Peter --- Tony Hain wrote: > Owen DeLong wrote: > > > > What if there is no downloader? It's very trivial to generate lots of > > outbound > > traffic to look like "upload" without anyone on the other end caring about > > what arrives. > > > > So... Under your model, ISP pays me to clog up his network with packets > > destined > > to non-existant sites and bills who, exactly to cover these costs? > > > I think you missed the point. Sending to non-existent sites will only lead > the provider back to you. Instead we should all generate continuous > low-level streams to Peter, who will then graciously pay for our connections > because he is receiving so much valuable content. ;) > > Tony > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From hannigan at renesys.com Wed Apr 19 17:37:42 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Wed, 19 Apr 2006 17:37:42 -0400 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: References: Message-ID: <7.0.1.0.2.20060419173230.022a7a60@renesys.com> At 05:08 PM 4/19/2006, Divins, David wrote: >Do irresponsible ISPs SWIP correctly to begin with? It seems to me that >any policy movement here is to help responsible parties comply. The >irresponsible ones don't care, they do what they want and that's that. > >The reality is a customer that I am concerned about using SWIP for will >never be seen un-obfuscated in whois--period, under any policy >construct. I'm not a lawyer. Any person/entity handling a lawful order for surveillance, (CALEA, Title III, State regulation, FISA, PATRIOT II, etc.) is responsible to keep that order confidential and secure. If the target of the order became aware of the order via whois (for our purpose) lookups that pointed to "National Security Agency", the provider or other entity would not be able to blame it on ARIN regardless of ARIN policy. It doesn't work that way. What I think you are describing is a clash of policy, operational procedure, and the law. That's why I characterized it as administrative and am proposing a concept similiar to confidential/undercover license plate. The process already exists outside of ARIN for reference. We can continue status quo, or adjust to reality. If we want to. [ Not to be confused with zip, or /29 policy parts, this one is all inclusive ] -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From stephen at sprunk.org Wed Apr 19 20:46:37 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 19 Apr 2006 19:46:37 -0500 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6Assignments for End Sites - Last Call References: <444003A2.10005@arin.net><20060417031941.GA28204@vaf-lnx1.cisco.com><878xq4l4d9.fsf@valhalla.seastrom.com><20060417163134.GA10419@vaf-lnx1.cisco.com><873bgcar1z.fsf@valhalla.seastrom.com><20060417204124.GX29385@shell01.corp.tellme.com> <25968EC2-98AB-4099-A850-D1D4CAE5FC19@muada.com> Message-ID: <009701c66413$e212d8c0$3712fea9@ssprunk> Thus spake "Iljitsch van Beijnum" > Question for those of you in favor of the policy proposal: > > If you're not ISP / IP carrier: > > Are you planning to obtain an IPv6 PI prefix as per the proposed > policy and then deploy, say, 25% or more of the services you now > provide over IPv4 over IPv6 using those addresses? And if so, how > soon would this happen? My employer will apply for a prefix as soon as we have at least two carriers that offer (a) native IPv4 and IPv6 on the same pipe, (b) at the same price as IPv4-only connectivity, and (c) agree to accept a PI route. Currently zero of our carriers meet either of the first two condititions (and we couldn't ask the last until now), but they'll be in the next RFP that goes out. I'm not sure when our current contracts are up for renewal, so I can't give a date, but IIRC it'll be within a year or so. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From stephen at sprunk.org Wed Apr 19 21:16:15 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 19 Apr 2006 20:16:15 -0500 Subject: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances inARIN] References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com><6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com><2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net><1145206143.23746.32.camel@firenze.zurich.ibm.com> <75cb24520604162210q39a2e1b0y4472325710970dd@mail.gmail.com> Message-ID: <013c01c66418$05a88240$3712fea9@ssprunk> Thus spake "Christopher Morrow" > On 4/16/06, Jeroen Massar wrote: >> The idea of IPv6 is (still not was) to have it around for quite some >> time longer than the lifespan of IPv4. Fortunately, the PI thing is far >> from the end of the world and will only help catch on, see below > > stopping the PI train is hardly a simple matter. I agree that failing > some reasonable 'multihoming' solution in v6, v6 is dead on arrival. I > don't see that PI space is a smart move for the long term though :( I don't think any of us who support this proposal think it's a great long-term move, but so far the IETF and RIRs have yet to come up with something better. If they had, we'd be supporting that instead. In the real world, you frequently have to pick the least-bad alternative, not the best one. This is what we've done here. > If PI space gets final approval it will mean that all of the DFZ > providers will have to carry all (or nearly all) /48 routes for > eternity... There is no way to get back the /48's assigned under PI > space after a multihoming solution that makes sense arrives, Blatantly untrue. ARIN (and any other RIRs that adopt similar policies) can certainly repeal the PI policy at any time and could, I assume, refuse to renew the existing assignments. As someone else noted, there will probably be proposals to do so in every policy cycle from now until such succeeds. Failing that, all the ISPs have to do is start filtering PI routes if/when they become a problem. If they don't filter the routes, obviously it's not an issue worth worrying about in the first place. > and there is, honestly, no driver to continue working on a multihoming > solution now that there is PI space. Yes, there is still a purpose in doing so, but it's admittedly less urgent now unless/until we see major ISPs refusing to route PI space. > Perhaps the original architects of v6 thought that by not proposing a > multihoming solution, multihoming wouldn't happen? or that someone > would arrive at a better solution than smaller deaggregates? Who > knows... The original architects of IPv6 were router vendors, who wanted an architecture that was cheaper to make routers for, and ISPs, who wanted cheaper routers. Non-ISP network operators are and have been absent from nearly all IETF activities. One can debate why that is, but the result is undeniably "solutions" that do not track the needs of the people paying the bills. Simply consider the IETF's stance against NAT in spite of nearly every host on the modern Internet being behind _at least_ one NAT device and you'll start to see the disconnect. > it seems that backing up, restarting the 'new protocol' process is > likely to end up with another 10 years wasted, so it's very hard to > see a reasonable path forward at this time. Ah, but that assumes we actually need to replace IPv6. It might be that we need to replace TCP, insert a layer below it, or replace BGP. An influx of "evil" PI routes may motivate the IETF to find a more attractive alternative; unfortunately, history shows they're more likely to bury their heads in the sand and pretend PI isn't happening. There's lots of possible solutions that can obviate the need for PI space (or, possibly, PA space) without changing the IPv6 forwarding logic. Hopefully the IETF will go figure out how to make one or more of them work. > you have some basis for this? I don't have that same faith... I think > that quite quickly every entity that has ipv4 space will have ipv6 > space in some PI fashion (if they have ipv4 PI space) and we'll all be > stuck routing that and more from now until eternity. That will > effectively double the current route table, which on much of the > deployed networks isn't such a good plan. Hardly. Many of the orgs that will be getting PIv6 space under this policy have _hundreds_ of PIv4 blocks. If we did our job right, each org will need only one PIv6 block per ASN, and there are not that many non-transit ASNs out there. We're talking about doubling or tripling the current v6 table, not adding the entire bloated, swampy v4 table to it. Just look at the number of prefixes in the v4 table vs the number of ASNs and you'll see that we're making an improvement of at least one order of magnitude. Pessimists, of course, will claim this will lead to an order of magnitude growth in ASN assignment, but given there's virtually no restrictions on getting an ASN and multihoming with v4, how can one propose that PIv6 space will grow faster than Moore's Law (and anything less than that is irrelevant)? S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From owen at delong.com Thu Apr 20 02:53:03 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Apr 2006 23:53:03 -0700 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: References: Message-ID: <8DC5DD3E3B401C0736CA981A@odpwrbook.hq.netli.lan> --On April 19, 2006 5:08:55 PM -0400 "Divins, David" wrote: > Do irresponsible ISPs SWIP correctly to begin with? It seems to me that > any policy movement here is to help responsible parties comply. The > irresponsible ones don't care, they do what they want and that's that. > While there may be some truth to that, codifying it as legitimate practice is not in my opinion in the best interests of correcting the problem. Businesses operating within the law in most jurisdictions have a business license which is a matter of public record and have filed a fictitious name or incorporation paperwork with a secretary of state office in some state, also a matter of public record. Lots of businesses operate outside of these laws. Does that mean that we should pass a law saying it is OK to do so? I tend to think not. > The reality is a customer that I am concerned about using SWIP for will > never be seen un-obfuscated in whois--period, under any policy > construct. That said; what I am looking for is a way as a responsible > party to have a mechanism to deal with these "corner cases" in an > appropriate manner. This may be a wacky case for a lot of people but it > is a majority of my customers. > Then, frankly, your customer should live in /29s or smaller, or, should create a legitimate ORG that handles all of their IP transactions and can accept legal service for whatever they do to the network. Current policy allows that ORG to be the party registered in ARIN whois. > I do not have all the answers but I believe there is something that can > be done in this space. > And I think that what we have is adequate, except, of course, that I would like to see some accountability brought against those that are placing fraudulent data in the database. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Thu Apr 20 04:42:54 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 20 Apr 2006 09:42:54 +0100 Subject: [ppml] New WHOIS policy approved In-Reply-To: Message-ID: > True, but, no longer particularly relevant to the practice > and purpose of either. Even back in the day of SRI InterNIC, > the use and content of IP registration whois data and Domain > whois data was different. I would say they are sisters, but, > I'm not so sure they're twins rather than step sisters. I think > they had different fathers. Go back further. Look at RFC 812 http://rfc.sunsite.dk/rfc/rfc812.html > I guess we can agree to disagree on this. I think that the amount > of indirection and misdirection allowed by ICANNs new domain > policy is a bad idea and I'd hate to see it added to ARIN > whois policy, no matter how convenient it is for BT. No need to sink to ad hominems... I am speaking in general terms at this point. Whois policy is creaky and ancient and full of holes. It makes sense to review it in the same way that ICANN has done. Check this page http://www.icann.org/announcements/announcement-18sep03.htm And follow up the links to the Montreal and Carthage workshops and their presentations. We don't need knee-jerk reactions but measured thought and analysis of where we are and where we should be. > > Note, that Domains and IPs do share some characteristics. > Domains are not associated with internet endpoints in any way > other than their ability to be mapped to an IP address. Domains > are loosely coupled with IP addresses. The only use of a domain > is to provide a handle for lookup in a directory. IP addresses, > OTOH, are used for traffic delivery and specify a particular > point on the internet (notwithstanding anycast and multicast > for the moment). Bingo! I see you agree with me that domains and IPs do share SOME characteristics. And that IP addresses are rather more restrictive in scope than domain names. This is why I believe we need to review our whois policy and fix it so that its scope is similarly restrictive. > I don't think that clarifying whois policy would be a bad thing > at all. I just don't want to see that clarification include > the kind of wiggle room just offered to spammers in the new > ICANN policy. ICANN policies and ARIN policies are the wrong place to combat spammers. That is a job for legislature, courts and police forces. It has taken a long time for those bodies to begin the work but now that they have done so, we should be supporting them and not allowing vigilante mentality to drive our policies. --Michael Dillon From Michael.Dillon at btradianz.com Thu Apr 20 05:18:43 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 20 Apr 2006 10:18:43 +0100 Subject: [ppml] New WHOIS policy approved In-Reply-To: Message-ID: > Go back further. Look at RFC 812 > http://rfc.sunsite.dk/rfc/rfc812.html Wrong reference. It is this document that goes back to 1970: http://web.archive.org/web/20021203012845/http://www.ifla.org/documents/internet/hari1.txt Also I forgot that SRI stands for Stanford Research Institute so you are correct that this is SRI-NIC times. The thesis mentions both the ARPANET directory on paper and the online NIC service. Also, the first SPAM sent in 1978 used the NIC directory to select recipients: http://www.templetons.com/brad/spamreact.html And the NIC directory was integral to some protocols such as FTP defined in RFC 385 http://www.ietf.org/rfc/rfc385.txt Look at paragraph 13. The original whois was an extremely simple protocol to allow direct network access to this NIC Name directory. You will note that the FTP definition assumed that the host would have complete copy of the NIC Name directory whereas whois allowed access to just the single entry that was required. To understand what the NIC was back in those days, RFC 115 http://www.ietf.org/rfc/rfc115.txt is useful to read. As you can see the NIC included functions that ended up outside of both ARIN and the domain name registries. This is the environment where the habit of filing whois entries originated. Since that time, there has not been any public scrutiny of these habits or the purpose behind them. Arguably, the world has changed a lot since ARPANET days and the functions of the original NICNAME/WHOIS directory has largely been distributed to ISPs and end user organizations who operate mail servers. It is time to take a comprehensive look at our whois policy and our whois directory. Martin Hannagan and David Divins have both pointed out different areas in which our inherited non-policy has problems. In 1992 a certain John Curran co-authored RFC 1355: http://www.ietf.org/rfc/rfc1355.txt I'm not certain that ARIN meets the standards set out in this RFC and I do not recall that ARIN's whois policy and procedures have ever been reviewed against this document. --Michael Dillon From pekkas at netcore.fi Thu Apr 20 09:48:30 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 16:48:30 +0300 (EEST) Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive Message-ID: Hi, I don't support PI space to end-sites. We have to get rid of the notion that a random end-site has any business whatsoever in mucking with the global routing tables, either by making it much larger than need be or by polluting it with needless dynamicity. Example of the latter: deploying inbound traffic engineering adjustment solutions which result in thousands of daily flaps in the advertisements, as shown by Huston's analysis. We have way too much trouble with clueless ISPs to also add (or continue to add) end-sites to the mix... .... Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through. If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance): 1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something. 2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters. 3. assignments from a separate address block, set aside for PI. To ease strict "assignment-size only" filtering of these blocks. -- 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 dlw+arin at tellme.com Thu Apr 20 09:56:48 2006 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 20 Apr 2006 06:56:48 -0700 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <20060420135648.GL16281@shell01.corp.tellme.com> On Thu, Apr 20, 2006 at 04:48:30PM +0300, Pekka Savola wrote: > I don't support PI space to end-sites. We have to get rid of the > notion that a random end-site has any business whatsoever in mucking > with the global routing tables, either by making it much larger than > need be or by polluting it with needless dynamicity. > > We have way too much trouble with clueless ISPs to also add (or > continue to add) end-sites to the mix... The message I'm getting from you is that people at end-sites are clueless idiots, and only large ISPs have enough clue to run BGP without mucking things up. I find that horribly offensive. I think there are people in the ISP community that have valid concerns about PI space. I disagree with them, but I can at least respect their views. This, on the other hand, has no merit in my book. I'm quite positive that many end-sites have legitimate need for controlling their own routing, and many are quite capable of doing so without making a mess of things. (I'd like to think that my site is among those.) -David From sleibrand at internap.com Thu Apr 20 10:10:22 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 20 Apr 2006 10:10:22 -0400 (EDT) Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On 04/20/06 at 4:48pm +0300, Pekka Savola wrote: > Now, from practical point of view, it seems there is strong "need" for > PI, and it might be a PI policy of some kind might actually get > through. Very true. I'd even s/might/will/. > If so, the policy should be such that it minimizes the bad effects of > PI and encourages people to use other solutions if those are viable > for them (unfortunately, the only way to achieve that appears to be > $$$$), in particular (in the rough order of importance): > > 1. Each assignment must be accompanied by a recurring fee (at least > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > (compared to other costs) to anyone who actually needs this > multihoming solution. However, this ensures at least some minimum > usage barrier ("those who don't really need this can use different > multihoming solutions"), and recovery of the resources back to RIR > after the company has gone bankrupt or no longer needs the addresses. > If you don't know where to put the extra money, donate it to ISOC or > something. As has been discussed at ARIN, this is a good way to get the government to declare the RIR a monopoly engaging in anticompetitive behavior. I for one don't want that. Now if you think ISPs should start charging end sites for the privilege of running BGP, that might fly. ISPs in the DFZ are bearing the costs of maintaining the extra routes*, so they can justify a per-route charge, and they actually have contracts with their customers, so they can collect. (* Yes, other end sites in the DFZ also bear those costs, but since they contribute routes to the table as well, and can sometimes switch to default-only BGP, I'd argue that DFZ ISPs are the ones stuck "holding the bag" of routing table growth.) > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > don't have much preference here), but you must not be able to justify > for larger space. This is to avoid the organization from getting a > larger block and chopping it into smaller pieces and polluting the > global routing table with more specifics which would get past prefix > length filters. With the current ARIN policy proposal, you'd get a /48, with a /44 reserved for growth. Would you advocate giving everyone a /44 up front instead? Or something else? I don't have too much preference here, FWIW. > 3. assignments from a separate address block, set aside for PI. To > ease strict "assignment-size only" filtering of these blocks. This is already a part of 2005-1, and has been a part (expressed or implied) of every other PI proposal I've seen. -Scott From pekkas at netcore.fi Thu Apr 20 10:18:47 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 17:18:47 +0300 (EEST) Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On Thu, 20 Apr 2006, Scott Leibrand wrote: >> 1. Each assignment must be accompanied by a recurring fee (at least >> 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts >> (compared to other costs) to anyone who actually needs this >> multihoming solution. However, this ensures at least some minimum >> usage barrier ("those who don't really need this can use different >> multihoming solutions"), and recovery of the resources back to RIR >> after the company has gone bankrupt or no longer needs the addresses. >> If you don't know where to put the extra money, donate it to ISOC or >> something. > > As has been discussed at ARIN, this is a good way to get the government to > declare the RIR a monopoly engaging in anticompetitive behavior. I for > one don't want that. I don't think that follows, but unless ARIN legal counsel or someone who is a real lawyer has made a statement here, I'm not sure how seriously to take this. Pointer to such official legal counsel would be appreciated. That is, ARIN has every right to require, for example, that everyone getting a prefix is (for instance) a member of ARIN, and charging for the membership should be OK. RIRs run on non-profit principle, but nothing precludes them from increasing the expenses, e.g., for donations to make the internet a better place, setting a foundation for multihoming research to actually SOLVE this problem, etc.etc. >> 2. one-size-fits-all assignments, period. You get a /48 or /32 (I >> don't have much preference here), but you must not be able to justify >> for larger space. This is to avoid the organization from getting a >> larger block and chopping it into smaller pieces and polluting the >> global routing table with more specifics which would get past prefix >> length filters. > > With the current ARIN policy proposal, you'd get a /48, with a /44 > reserved for growth. Would you advocate giving everyone a /44 up front > instead? Or something else? I don't have too much preference here, FWIW. I wouldn't object to reserving a /44 just in case, but make no provisions (at this point) for applying more. If someone needs more than /48, it needs to justify another one, and get a separate /48 (with its own reserved /44). -- 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 dlw+arin at tellme.com Thu Apr 20 10:25:07 2006 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 20 Apr 2006 07:25:07 -0700 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <20060420142507.GO16281@shell01.corp.tellme.com> On Thu, Apr 20, 2006 at 05:18:47PM +0300, Pekka Savola wrote: > RIRs run on non-profit principle, but nothing precludes them from > increasing the expenses, e.g., for donations to make the internet a > better place, setting a foundation for multihoming research to > actually SOLVE this problem, etc.etc. Now *that* is a good idea. -David From narten at us.ibm.com Thu Apr 20 10:34:46 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 20 Apr 2006 10:34:46 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: Message from Randy Bush of "Sat, 15 Apr 2006 04:44:39 -1000." <17473.1751.659052.317012@roam.psg.com> Message-ID: <200604201434.k3KEYkrW021376@cichlid.raleigh.ibm.com> > > the /64 boundary is hardwired in a lot of places and so that is > > contraindicated. > it was specified NOT to be hardwired. Right. Unfortunately, it's possible to argue both sides of this. Here is what I wrote on this in http://tools.ietf.org/html?draft=draft-narten-iana-rir-ipv6-considerations > 5.3. On the /64 Boundary > > In theory, even more savings could be realized by reducing the size > of the Interface identifier, i.e., making it smaller than 64 bits. > While possible, this is the most difficult boundary to move in > practice. Considerations include: > > - Stateless address autoconfiguration [RFC 2462] assumes Interface > identifiers are fixed at 64 bits. Changing this would require > revising that specification and devising a transition plan for > migrating existing implementations from 64-bit identifiers to > something shorter. > - Stateless address autoconfiguration has been widely implemented, > with additional implementations in the pipeline. Removing those > implementations and replacing them with upgraded implementations > will take many years. > > - it is unclear how one would transition to Interface identifiers > of shorter length in the short term while preserving stateless > address autoconfiguration. > > - one transition strategy might be to disable stateless address > autoconfiguration completely (for generating addresses) and use > DHCP to assign addresses. However, client implementation of DHC > for address configuration is not mandatory in IPv6, and it is > believed that few IPv6 devices actually implement the client > portion of address configuration via DHC. > > - some existing IPv6 multicast standards assume that an IPv6 > routing prefix is no more than 64-bits in length, and include > the 64-bit subnet prefix within an IPv6 multicast address > [RFC3306,RFC3956]. Actually, the text about stateless addrconf is not quite true. Stateless addrconf can handle any prefix length, but the real issue is that it contains the following line: > If the sum of the prefix length and interface identifier length > does not equal 128 bits, the Prefix Information option MUST be > ignored. The rules for constructing interface identifiers are specific to each link-layer type (e.g., ethernet vs. token ring vs. ...). And in all the individual IPv6-over-linklayer documents, the interface identifier is specified to be 64 bits. Plus, RFC 4291 "IP Version 6 Addressing Architecture" does say: > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. So, if one wants to use stateless addr conf, we've effectively wired in /64. Thomas From Ed.Lewis at neustar.biz Thu Apr 20 10:48:28 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 20 Apr 2006 10:48:28 -0400 Subject: [ppml] funding multihoming work was Re: Just say *NO* to PI space In-Reply-To: <20060420142507.GO16281@shell01.corp.tellme.com> References: <20060420142507.GO16281@shell01.corp.tellme.com> Message-ID: At 7:25 -0700 4/20/06, David Williamson wrote: >On Thu, Apr 20, 2006 at 05:18:47PM +0300, Pekka Savola wrote: >> RIRs run on non-profit principle, but nothing precludes them from >> increasing the expenses, e.g., for donations to make the internet a >> better place, setting a foundation for multihoming research to >> actually SOLVE this problem, etc.etc. > >Now *that* is a good idea. At what point does an RIR go from increasing fees to funnel money into research initiatives to being a governmental body levying taxes to fund public works? I'm not an economist/lawyer, I don't have the facts to argue against the suggestion above, but that question epitomizes the danger of a private (although non-profit) from playing economic games. The RIRs have to remain neutral. Cost-recovery and good stewards. Cost-recovery means no excess in the fees. Stewards means having discretionary funds to maintain SLAs (sub-bullet: fiscally sound, insurance coverage too). More than that and you are treading beyond what *might be* legally permitted. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From Michael.Dillon at btradianz.com Thu Apr 20 10:57:35 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 20 Apr 2006 15:57:35 +0100 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: Message-ID: > I don't support PI space to end-sites. We have to get rid of the > notion that a random end-site has any business whatsoever in mucking > with the global routing tables, either by making it much larger than > need be or by polluting it with needless dynamicity. PI allocations do not allow prefixes into the global routing table. That is something that ISPs do and it is outside of ARIN's control. Historically, ISPs have filtered prefixes that fell below some arbitrary threshold when it was necessary to protect the viability of their networks. Then, when new technology solved the problems, they eased up on those filters. ARIN's IPv6 PI policy does not inhibit the ability of ISPs to take similar action, if and when they determine that there is a real imminent technical issue with the global routing table. Current analysis shows that because the IPv6 routing table is an order of magnitude smaller than the IPv4 table, there is no current imminent issue. Therefore many of us, me included, feel that it is prudent to release PI IPv6 addresses to give the end users and ISPs the ability to try this out on the real network. > If so, the policy should be such that it minimizes the bad effects of > PI and encourages people to use other solutions if those are viable > for them (unfortunately, the only way to achieve that appears to be > $$$$), in particular (in the rough order of importance): > > 1. Each assignment must be accompanied by a recurring fee (at least > 1000-2000 USD/EUR a year, preferably 5000+). This type of punitive fee is impossible for two reasons. One is that ARIN policies may not specify fees. The other is that punitive fees would be in violation of U.S. restraint of trade legislation. In fact, it is possible that disallowing PI IPv6 allocations is, itself, a violation of restraint of trade laws. It is not within ARIN's scope to be an architect of the Internet marketplace. We can only put in place policies which allow that market to develop in a manner that is fair and roughly balances the interests of all parties. I don't believe that 2005-1 is a perfect policy, nevertheless I do support moving forward with 2005-1 as it is currently. --Michael Dillon From packetgrrl at gmail.com Thu Apr 20 11:15:53 2006 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 20 Apr 2006 09:15:53 -0600 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: Michael, The difference between the historic filters that ISPs imposed is that the longer blocks they filtered were also still advertised via shorter aggregate CIDR blocks. This meant that multihomed sites were still reachable although not optimally. If an ISP filters these PI blocks when their routers are starting to die, that ISPs customers will not be able to get to these sites at all. The IPv4 swamp of PI /24s was specifically not filtered for this very reason. ---Cathy On 4/20/06, Michael.Dillon at btradianz.com wrote: > > > I don't support PI space to end-sites. We have to get rid of the > > notion that a random end-site has any business whatsoever in mucking > > with the global routing tables, either by making it much larger than > > need be or by polluting it with needless dynamicity. > > PI allocations do not allow prefixes into the global > routing table. That is something that ISPs do and it is > outside of ARIN's control. Historically, ISPs have filtered > prefixes that fell below some arbitrary threshold when it > was necessary to protect the viability of their networks. > Then, when new technology solved the problems, they eased > up on those filters. ARIN's IPv6 PI policy does not inhibit > the ability of ISPs to take similar action, if and when they > determine that there is a real imminent technical issue with > the global routing table. Current analysis shows that because > the IPv6 routing table is an order of magnitude smaller than > the IPv4 table, there is no current imminent issue. Therefore > many of us, me included, feel that it is prudent to release > PI IPv6 addresses to give the end users and ISPs the ability > to try this out on the real network. > > > If so, the policy should be such that it minimizes the bad effects of > > PI and encourages people to use other solutions if those are viable > > for them (unfortunately, the only way to achieve that appears to be > > $$$$), in particular (in the rough order of importance): > > > > 1. Each assignment must be accompanied by a recurring fee (at least > > 1000-2000 USD/EUR a year, preferably 5000+). > > This type of punitive fee is impossible for two reasons. One is > that ARIN policies may not specify fees. The other is that > punitive fees would be in violation of U.S. restraint of trade > legislation. In fact, it is possible that disallowing PI IPv6 > allocations is, itself, a violation of restraint of trade laws. > It is not within ARIN's scope to be an architect of the Internet > marketplace. We can only put in place policies which allow > that market to develop in a manner that is fair and roughly > balances the interests of all parties. > > I don't believe that 2005-1 is a perfect policy, nevertheless > I do support moving forward with 2005-1 as it is currently. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Thu Apr 20 11:25:14 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 20 Apr 2006 11:25:14 -0400 (EDT) Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On 04/20/06 at 9:15am -0600, cja at daydream.com wrote: > The difference between the historic filters that ISPs imposed is that the > longer blocks they filtered were also still advertised via shorter aggregate > CIDR blocks. This meant that multihomed sites were still reachable although > not optimally. If an ISP filters these PI blocks when their routers are > starting to die, that ISPs customers will not be able to get to these sites > at all. *Unless* you replace the filtered PI blocks with a supernet aggregate. For example, if an ISP in Asia decided they couldn't handle all the ARIN PI netblocks, they could create a route for the ARIN PI supernet pointed toward North America and filter all the PI subnets. If we decide to assign PI space on a non-random basis, we set ourselves up to be able to do the same thing on less than continental scales *if* it becomes necessary at some point. Hopefully that won't be necessary, but IMO non-random PI assignment is a very cheap and easy emergency preparedness measure. -Scott > The IPv4 swamp of PI /24s was specifically not filtered for this > very reason. > > ---Cathy > > On 4/20/06, Michael.Dillon at btradianz.com > wrote: > > > > > I don't support PI space to end-sites. We have to get rid of the > > > notion that a random end-site has any business whatsoever in mucking > > > with the global routing tables, either by making it much larger than > > > need be or by polluting it with needless dynamicity. > > > > PI allocations do not allow prefixes into the global > > routing table. That is something that ISPs do and it is > > outside of ARIN's control. Historically, ISPs have filtered > > prefixes that fell below some arbitrary threshold when it > > was necessary to protect the viability of their networks. > > Then, when new technology solved the problems, they eased > > up on those filters. ARIN's IPv6 PI policy does not inhibit > > the ability of ISPs to take similar action, if and when they > > determine that there is a real imminent technical issue with > > the global routing table. Current analysis shows that because > > the IPv6 routing table is an order of magnitude smaller than > > the IPv4 table, there is no current imminent issue. Therefore > > many of us, me included, feel that it is prudent to release > > PI IPv6 addresses to give the end users and ISPs the ability > > to try this out on the real network. > > > > > If so, the policy should be such that it minimizes the bad effects of > > > PI and encourages people to use other solutions if those are viable > > > for them (unfortunately, the only way to achieve that appears to be > > > $$$$), in particular (in the rough order of importance): > > > > > > 1. Each assignment must be accompanied by a recurring fee (at least > > > 1000-2000 USD/EUR a year, preferably 5000+). > > > > This type of punitive fee is impossible for two reasons. One is > > that ARIN policies may not specify fees. The other is that > > punitive fees would be in violation of U.S. restraint of trade > > legislation. In fact, it is possible that disallowing PI IPv6 > > allocations is, itself, a violation of restraint of trade laws. > > It is not within ARIN's scope to be an architect of the Internet > > marketplace. We can only put in place policies which allow > > that market to develop in a manner that is fair and roughly > > balances the interests of all parties. > > > > I don't believe that 2005-1 is a perfect policy, nevertheless > > I do support moving forward with 2005-1 as it is currently. > > > > --Michael Dillon > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > -------------- next part -------------- _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Thu Apr 20 11:26:52 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 20 Apr 2006 16:26:52 +0100 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: Message-ID: > > As has been discussed at ARIN, this is a good way to get the government to > > declare the RIR a monopoly engaging in anticompetitive behavior. I for > > one don't want that. > > I don't think that follows, but unless ARIN legal counsel or someone > who is a real lawyer has made a statement here, I'm not sure how > seriously to take this. Pointer to such official legal counsel would > be appreciated. Those of us who have lived and worked in North America or the UK, have a general understanding of this because restraint of trade doctrine is a part of English common law which was then inherited by other countries such as Canada and the USA. However, European competition law is not based on the same principles and in the UK today, there are often conflicts between the doctrine of restraint of trade and European competition law. If you are interested in understanding this then start here http://nys-stlc.syr.edu/lawlibrary/antitrust/antitrustbasics.aspx The important bit is the RULE OF REASON towards the bottom. If your English is advanced enough, then you could try reading legislation such as the Sherman Act, but you may find that lawyers like to use common words in uncommon ways. This illustrates the wisdom of the industry driven bottom-up policy development process that results in ARIN developing IP address policy in North America and RIPE doing the same job in Europe. There are different norms of society and of law in these different places. The people of North America would probably view your position as a SOCIALIST one and see that as a very negative thing. However, in Europe, people will tend to see your position as a SOCIALIST one and see that as a good thing. Because you are crossposting this thread to a global V6 list and to a RIPE mailing list, it seems to me that you feel there should be a single unitary global policy. However, that is contrary to the structure of the RIR system, contrary to NRO policy and contrary to the outcome of last autumns WSIS meetings. Policy proposal 2005-1 is an ARIN proposal that has worked its way through the ARIN policy process. We discussed it intensely at the recent ARIN meeting in Montreal and it was broadly accepted by the participants at that meeting. It is highly likely that it will become part of ARIN policy and ARIN *WILL* be issuing PI IPv6 blocks by the end of the year. You are welcome to register your disapproval, however so many people have worked to develop this reasonable compromise that I don't think you will be able to sway any of them. > RIRs run on non-profit principle, but nothing precludes them from > increasing the expenses, e.g., for donations to make the internet a > better place, setting a foundation for multihoming research to > actually SOLVE this problem, etc.etc. I'm not sure if research is within ARIN's scope, however even if it is, we cannot delay deployment of IPv6 merely because there is still a need for research. Throughout the deployment of IPv4 and the astronomical growth of the Internet, both research and commercial deployment happened simultaneously and the results brought major benefits to society, even if it did mean a lot of struggle with imperfections. > I wouldn't object to reserving a /44 just in case, but make no > provisions (at this point) for applying more. If someone needs more > than /48, it needs to justify another one, and get a separate /48 > (with its own reserved /44). I think you misunderstand ARIN's allocation algorithm here. The purpose of a reserved block is to allow an applicant to receive an increased allocation from the reserved block in order to be able to aggregate the new and old allocations. If the recipient of a /48 allocation applies for more and receieves the rest of their reserved /44 then they can announce a single /44 prefix instead of two /48 prefixes (or more). This minimizes the impact on the global routing table. The ARIN IPv4 allocation algorithm works the same way. --Michael Dillon From tme at multicasttech.com Thu Apr 20 11:27:10 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 20 Apr 2006 11:27:10 -0400 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <2172B978-2048-41EC-8713-4E811A6599E1@multicasttech.com> On Apr 20, 2006, at 11:15 AM, cja at daydream.com wrote: > Michael, > > The difference between the historic filters that ISPs imposed is > that the longer blocks they filtered were also still advertised via > shorter aggregate CIDR blocks. This meant that multihomed sites > were still reachable I can attest that this was not always the case. I know for a fact that some places were at some times black-holed. (Any time that RPF checks are on this is a likelihood if multi-homed sites are aggregated.) Regards Marshall > although not optimally. If an ISP filters these PI blocks when > their routers are starting to die, that ISPs customers will not be > able to get to these sites at all. The IPv4 swamp of PI /24s was > specifically not filtered for this very reason. > > ---Cathy > > On 4/20/06, Michael.Dillon at btradianz.com < > Michael.Dillon at btradianz.com> wrote:> I don't support PI space to > end-sites. We have to get rid of the > > notion that a random end-site has any business whatsoever in mucking > > with the global routing tables, either by making it much larger than > > need be or by polluting it with needless dynamicity. > > PI allocations do not allow prefixes into the global > routing table. That is something that ISPs do and it is > outside of ARIN's control. Historically, ISPs have filtered > prefixes that fell below some arbitrary threshold when it > was necessary to protect the viability of their networks. > Then, when new technology solved the problems, they eased > up on those filters. ARIN's IPv6 PI policy does not inhibit > the ability of ISPs to take similar action, if and when they > determine that there is a real imminent technical issue with > the global routing table. Current analysis shows that because > the IPv6 routing table is an order of magnitude smaller than > the IPv4 table, there is no current imminent issue. Therefore > many of us, me included, feel that it is prudent to release > PI IPv6 addresses to give the end users and ISPs the ability > to try this out on the real network. > > > If so, the policy should be such that it minimizes the bad > effects of > > PI and encourages people to use other solutions if those are viable > > for them (unfortunately, the only way to achieve that appears to be > > $$$$), in particular (in the rough order of importance): > > > > 1. Each assignment must be accompanied by a recurring fee (at > least > > 1000-2000 USD/EUR a year, preferably 5000+). > > This type of punitive fee is impossible for two reasons. One is > that ARIN policies may not specify fees. The other is that > punitive fees would be in violation of U.S. restraint of trade > legislation. In fact, it is possible that disallowing PI IPv6 > allocations is, itself, a violation of restraint of trade laws. > It is not within ARIN's scope to be an architect of the Internet > marketplace. We can only put in place policies which allow > that market to develop in a manner that is fair and roughly > balances the interests of all parties. > > I don't believe that 2005-1 is a perfect policy, nevertheless > I do support moving forward with 2005-1 as it is currently. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From pekkas at netcore.fi Thu Apr 20 11:28:41 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 18:28:41 +0300 (EEST) Subject: [ppml] [address-policy-wg] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On Thu, 20 Apr 2006, Joao Damas wrote: >>> As has been discussed at ARIN, this is a good way to get the government to >>> declare the RIR a monopoly engaging in anticompetitive behavior. I for >>> one don't want that. > > Pekka, this doesn't sound like the right way to do policy, and yes, > things that smell like "big guys get it, small guys don't" will be > looked at suspiciously and rightly so. Criteria ought to be of a > technical nature. I'm assuming this is already in reference to, "PI should cost money" instead of "PI shouldn't be available, period"... Larger end-sites already have 10-20k+ annual budget (most have much, much larger than that): caused by CAPEX by getting at least two routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and salaries of network engineering staff. AFAICS, whether or not a PI space would cost 0, 1000 or 5000 USD a year is NOT a barrier for entry. It's just *one* metric (you may be able to think of technical metrics that could imply the same, I can't) to say, "if you REALLY don't need this, it'd be nice if you seriously consider PA address space". > Don't want PI: propose a feasible alternative that provides the same > functionality under the current routing system, while looking for a better > system Use PA addresses and Unique Local Addresses if you really think you need them. Push for shim6. Put some work on solving the remaining problems if there really are any that aren't caused by the desire to graze the commons for free. Maybe I should have snipped this quote, as this seems like a rathole which isn't worth exploring (again) here... -- 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 Apr 20 11:34:18 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 20 Apr 2006 16:34:18 +0100 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: Message-ID: > If we decide to assign PI space on a non-random basis, we set ourselves up > to be able to do the same thing on less than continental scales *if* it > becomes necessary at some point. Hopefully that won't be necessary, but > IMO non-random PI assignment is a very cheap and easy emergency > preparedness measure. Given that intercontinental connections in and out of the ARIN region tend to be either East coast or West coast, it would not be much work to take the larger aggregate and allocate from the top for Western applicants and from the bottom for Eastern applicants. In the USA, use the Mississippi as the East-West border. In Canada use the Ontario-Manitoba border since Canadians traditionally consider Manitoba to be the easternmost of the western provinces. This is easy to implement and allows for a better than continental aggregation to be used if a crisis is ever reached. It seems prudent to me and I doubt that any policy is needed for this to be done. The ARIN Board of Trustees has the power to instruct staff on this, and in the past, allocation algorithms have been adjusted without policy action. I hope the Board will consider this suggestion seriously when they review the 2005-1 proposal. --Michael Dillon From pekkas at netcore.fi Thu Apr 20 12:15:15 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 19:15:15 +0300 (EEST) Subject: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On Thu, 20 Apr 2006, Michael.Dillon at btradianz.com wrote: >> I don't think that follows, but unless ARIN legal counsel or someone >> who is a real lawyer has made a statement here, I'm not sure how >> seriously to take this. Pointer to such official legal counsel would >> be appreciated. >... > If you are interested in understanding this then start here > http://nys-stlc.syr.edu/lawlibrary/antitrust/antitrustbasics.aspx This includes important gold nuggets such as ".. whether the practice complained of _unreasonably_ restrains competition", "The true test of legality is whether the restraint imposed is such as _merely regulates_ and perhaps thereby promotes competition ..." .. which imply that reasonable restraints may be OK (and many could count e.g., continued well-being of the common Internet routing system a reasonable thing), or that such acts may not necessarily be restrictive, but rather leveling the competion. But all of this is irrelevant, as I'm not interested in your or my arm-chair lawyering. I'm interested in reference to what ARIN legal counsel has said on this. > Because you are crossposting this thread to a global V6 list > and to a RIPE mailing list, it seems to me that you feel there > should be a single unitary global policy. No, the discussion has been recently brought up at least on those lists, and it would seem unwise to repeat it on every list. Even if each region made its own policies, it might be much easier for everyone (IMHO) if the discussion was held on a common list, and then when the time comes, folks would each go to their own individual RIR to make their informed or uninformed decisions. >> I wouldn't object to reserving a /44 just in case, but make no >> provisions (at this point) for applying more. If someone needs more >> than /48, it needs to justify another one, and get a separate /48 >> (with its own reserved /44). > > I think you misunderstand ARIN's allocation algorithm here. The purpose > of a reserved block is to allow an applicant to receive an increased > allocation from the reserved block in order to be able to aggregate > the new and old allocations. If the recipient of a /48 allocation > applies for more and receieves the rest of their reserved /44 then > they can announce a single /44 prefix instead of two /48 prefixes (or > more). > This minimizes the impact on the global routing table. The ARIN IPv4 > allocation algorithm works the same way. I understand the policy very well. If the above only were the case. The possible outcomes are (in an example case of expansion to /47): - the site advertises a 2001:db8:0::/47 - the site advertises a 2001:db8:0::/48 and 2001:db8:1::/48 - the site advertises a 2001:db8:0::/47 and one of /48's - the site advertises a 2001:db8:0::/47 and both of /48's Based on observations in v4 land, there are sites that specifically want to do something other than the first option, and I specifically want to preclude them from doing so. For almost every site, a /48 is enough. For those for whom it's not enough, they already want separable advertisements for TE purposes (e.g., multiple data centers), so they need either multiple /48's or tricks like above in any case. -- 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 stephen at sprunk.org Thu Apr 20 12:19:07 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 20 Apr 2006 11:19:07 -0500 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive References: Message-ID: <054601c66496$60f6b210$3712fea9@ssprunk> Thus spake "Pekka Savola" > On Thu, 20 Apr 2006, Scott Leibrand wrote: >>> 1. Each assignment must be accompanied by a recurring fee (at least >>> 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts >>> (compared to other costs) to anyone who actually needs this >>> multihoming solution. However, this ensures at least some minimum >>> usage barrier ("those who don't really need this can use different >>> multihoming solutions"), and recovery of the resources back to RIR >>> after the company has gone bankrupt or no longer needs the addresses. >>> If you don't know where to put the extra money, donate it to ISOC or >>> something. I think that the multihoming requirement will be enough to keep the number of assignments reasonable; if you look at the actual number of non-transit ASNs in the v4 table, it's not all that large. If we assume one PIv6 prefix per non-transit ASN, which is the goal, we're looking at under 10k routes from the ARIN region. >> As has been discussed at ARIN, this is a good way to get the >> government to declare the RIR a monopoly engaging in anticompetitive >> behavior. I for one don't want that. > > I don't think that follows, but unless ARIN legal counsel or someone > who is a real lawyer has made a statement here, I'm not sure how > seriously to take this. Pointer to such official legal counsel would > be appreciated. > > That is, ARIN has every right to require, for example, that everyone > getting a prefix is (for instance) a member of ARIN, and charging for > the membership should be OK. I'd want a lawyer to sign off on it. You're talking about deliberately charging an excessive fee to make it more difficult for smaller companies to compete with larger ones. That has the appearance of an industry cartel creating artificial barriers to lock their smaller competitors out of the market, and the FTC generally doesn't like that. Then again, IANAL. > RIRs run on non-profit principle, but nothing precludes them from > increasing the expenses, e.g., for donations to make the internet a > better place, That's an interesting thought, but siphoning off fees for other purposes (no matter how noble or popular) is a slippery slope. Let's keep the RIRs focused on what they were created for and on a cost-recovery basis, and members who want to donate to ISOC or other groups can do so. > setting a foundation for multihoming research to actually SOLVE this > problem, etc.etc. In theory, we already have a group tasked with that: the IETF. Are you proposing that RIRs start developing protocols outside the IETF? Or funding people to work full-time in the IETF on problems pertinent to RIRs? Again, this is a slippery slope and distracts from the RIRs' purpose. I definitely encourage the folks that are against PIv6 to work on better solutions, but IMHO the RIRs are not the correct vehicle or forum for that. ARIN is already treading on thin ice by rejecting the IETF's addressing plan. >>> 2. one-size-fits-all assignments, period. You get a /48 or /32 (I >>> don't have much preference here), but you must not be able to justify >>> for larger space. This is to avoid the organization from getting a >>> larger block and chopping it into smaller pieces and polluting the >>> global routing table with more specifics which would get past prefix >>> length filters. >> >> With the current ARIN policy proposal, you'd get a /48, with a /44 >> reserved for growth. Would you advocate giving everyone a /44 up front >> instead? Or something else? I don't have too much preference here, >> FWIW. > > I wouldn't object to reserving a /44 just in case, but make no > provisions (at this point) for applying more. If someone needs more > than /48, it needs to justify another one, and get a separate /48 > (with its own reserved /44). So instead of giving an org a /47, which _could_ be advertised as a single route, you'd prefer to give them two /48s, which _must_ be advertised as two routes? That seems to increase routing table pollution, not reduce it. Also, what's the point of reserving a /44, or worse multiple /44s, if we're only going to let people use a /48? That seems to defeat the purpose of having a reserved block. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From tme at multicasttech.com Thu Apr 20 12:32:23 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 20 Apr 2006 12:32:23 -0400 Subject: [ppml] [address-policy-wg] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <5BD9BD06-D30E-4FDD-89A8-837ECBAF4566@multicasttech.com> Hello; On Apr 20, 2006, at 11:28 AM, Pekka Savola wrote: > On Thu, 20 Apr 2006, Joao Damas wrote: >>>> As has been discussed at ARIN, this is a good way to get the >>>> government to >>>> declare the RIR a monopoly engaging in anticompetitive >>>> behavior. I for >>>> one don't want that. >> >> Pekka, this doesn't sound like the right way to do policy, and yes, >> things that smell like "big guys get it, small guys don't" will be >> looked at suspiciously and rightly so. Criteria ought to be of a >> technical nature. > > I'm assuming this is already in reference to, "PI should cost money" > instead of "PI shouldn't be available, period"... > > Larger end-sites already have 10-20k+ annual budget (most have much, > much larger than that): caused by CAPEX by getting at least two > routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and > salaries of network engineering staff. > Yes, but I know many of people (including myself and basically all of my clients) who would regard a $ 5K tax as pretty onerous. You also run the risk of giving people the feeling that the system is weighted towards the large stakeholders. Now, I do not feel that way, but I hear from plenty of people who do, and it's hard to see how they wouldn't take it this way. Regards Marshall > AFAICS, whether or not a PI space would cost 0, 1000 or 5000 USD a > year is NOT a barrier for entry. It's just *one* metric (you may be > able to think of technical metrics that could imply the same, I can't) > to say, "if you REALLY don't need this, it'd be nice if you seriously > consider PA address space". > >> Don't want PI: propose a feasible alternative that provides the same >> functionality under the current routing system, while looking for >> a better >> system > > Use PA addresses and Unique Local Addresses if you really think you > need them. Push for shim6. Put some work on solving the remaining > problems if there really are any that aren't caused by the desire to > graze the commons for free. > > Maybe I should have snipped this quote, as this seems like a rathole > which isn't worth exploring (again) here... > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From mpetach at netflight.com Thu Apr 20 12:59:01 2006 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 20 Apr 2006 09:59:01 -0700 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised In-Reply-To: <17472.692.685697.785280@roam.psg.com> References: <443FFFC6.1060208@arin.net> <17472.692.685697.785280@roam.psg.com> Message-ID: <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> On 4/14/06, Randy Bush wrote: > > fwiw, after discussion with jason, i would support a more simple, direct, > and clear proposal to the same end. > > randy We would likewise vote in favour of the proposal were it to be tightened up and clarified more; currently, the model of burning a /32 for router loopbacks seems overly wasteful of address space; being able to use a /48 for this would be a far better choice. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.feldman at cnet.com Thu Apr 20 13:27:39 2006 From: steven.feldman at cnet.com (Steve Feldman) Date: Thu, 20 Apr 2006 10:27:39 -0700 Subject: [ppml] [address-policy-wg] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <5BD9BD06-D30E-4FDD-89A8-837ECBAF4566@multicasttech.com> References: <5BD9BD06-D30E-4FDD-89A8-837ECBAF4566@multicasttech.com> Message-ID: >>> Pekka, this doesn't sound like the right way to do policy, and yes, >>> things that smell like "big guys get it, small guys don't" will be >>> looked at suspiciously and rightly so. Criteria ought to be of a >>> technical nature. >> >> I'm assuming this is already in reference to, "PI should cost money" >> instead of "PI shouldn't be available, period"... >> >> Larger end-sites already have 10-20k+ annual budget (most have much, >> much larger than that): caused by CAPEX by getting at least two >> routers, OPEX by paying to multiple ISPs for fibers, transit, etc. >> and >> salaries of network engineering staff. >> > > Yes, but I know many of people (including myself and basically all of > my clients) who > would regard a $ 5K tax as pretty onerous. > > You also run the risk of giving people the feeling that the system is > weighted towards > the large stakeholders. Now, I do not feel that way, but I hear from > plenty of people who do, > and it's hard to see how they wouldn't take it this way. It doesn't make much sense to me for an RIR to charge large fees for v6 PI assignments, doing so is essentially behavior modification through taxation. On the other hand, it make perfect sense for anyone who wants their PI space advertised to pay their upstreams for the privilege, since there is a real cost in doing so. Also, it's naive to think that we won't ever have to pay for another round of router upgrades across the Internet; the only question is how long it can be delayed. Perhaps this time, though, it can be funded by the providers' customers, not the stockholders and creditors. Steve From mpetach at netflight.com Thu Apr 20 13:28:29 2006 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 20 Apr 2006 10:28:29 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call In-Reply-To: <25968EC2-98AB-4099-A850-D1D4CAE5FC19@muada.com> References: <444003A2.10005@arin.net> <20060417031941.GA28204@vaf-lnx1.cisco.com> <878xq4l4d9.fsf@valhalla.seastrom.com> <20060417163134.GA10419@vaf-lnx1.cisco.com> <873bgcar1z.fsf@valhalla.seastrom.com> <20060417204124.GX29385@shell01.corp.tellme.com> <25968EC2-98AB-4099-A850-D1D4CAE5FC19@muada.com> Message-ID: <63ac96a50604201028v54f26bc6q5b5de27fb9050d5f@mail.gmail.com> On 4/17/06, Iljitsch van Beijnum wrote: > > On 17-apr-2006, at 22:41, David Williamson wrote: > > > Oh, and in case it isn't obvious, I'm very much in favor of 2005-1. I > > think PI space until such time as it isn't needed (if ever...) is far > > preferable to nothing deployed and running out of v4 space. Yes, > > there's a ways to go before that event, but it's coming soon enough to > > already look to me like a train wreck. > > Question for those of you in favor of the policy proposal: > > If you're not ISP / IP carrier: > Are you planning to obtain an IPv6 PI prefix as per the proposed > policy and then deploy, say, 25% or more of the services you now > provide over IPv4 over IPv6 using those addresses? And if so, how > soon would this happen? Yes; within the next four years. (also a vote in support of 2005-1) Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry.l.davis at boeing.com Thu Apr 20 13:35:01 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Thu, 20 Apr 2006 10:35:01 -0700 Subject: [ppml] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BF4F@XCH-NW-8V1.nw.nos.boeing.com> Scott Good points. I might also ask folks to think back to the mid-nineties when the v6 designs were initiated. In 95 few businesses considered their network links to be "business critical", we couldn't have known that the corporate world would expect network reliability of 5 9's as a baseline today. Nor could we have guessed even in 2000 that our network reliability and outage recovery plans would be part our Sarbanes-Oxley audits. What I can tell you now is that because of these fundamental changes in business globally, the deployment model we envisioned in the mid-nineties won't work for business today. -There is simply no way that large corporations would sign up with a "single provider" for their IP addresses. The network is now the life blood of business and I don't know of any business executive that would permit themselves to be tied to a single supplier for something so critical to their bottom line. -Likewise, multi-homing to business is now a de-facto network expectation of most large corporations. As I said, they expect to deploy regional/national/global networks that have seamless connectivity with their sites and 5 9's or better of reliability. -I'm not even sure if a single service provider for this level of business criticality would pass the Sarbanes-Oxley audits. Business, in the post Enron environment, has a level of responsibility to their shareholders that they never could have envisioned a decade ago. In the decade it has taken us to be ready to deploy IP-v6, the world we based many of the deployment concepts of IP-v6 on has changed radically. We need to find a way to accommodate these changes in the relationship of the network to business; PI space is the only concept that I have seen so far that will provide business with the service model they now need. I'm virtually certain that most large and/or international corporations won't deploy IP-v6 unless they can make the service model fit their business needs. Take care Terry > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Thursday, April 20, 2006 7:10 AM > To: Pekka Savola > Cc: ppml at arin.net; address-policy-wg at ripe.net; global-v6 at lists.apnic.net > Subject: Re: [ppml] Just say *NO* to PI space -- or how to make it > lessdestructive > > On 04/20/06 at 4:48pm +0300, Pekka Savola wrote: > > > Now, from practical point of view, it seems there is strong "need" for > > PI, and it might be a PI policy of some kind might actually get > > through. > > Very true. I'd even s/might/will/. > > > If so, the policy should be such that it minimizes the bad effects of > > PI and encourages people to use other solutions if those are viable > > for them (unfortunately, the only way to achieve that appears to be > > $$$$), in particular (in the rough order of importance): > > > > 1. Each assignment must be accompanied by a recurring fee (at least > > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > > (compared to other costs) to anyone who actually needs this > > multihoming solution. However, this ensures at least some minimum > > usage barrier ("those who don't really need this can use different > > multihoming solutions"), and recovery of the resources back to RIR > > after the company has gone bankrupt or no longer needs the addresses. > > If you don't know where to put the extra money, donate it to ISOC or > > something. > > As has been discussed at ARIN, this is a good way to get the government to > declare the RIR a monopoly engaging in anticompetitive behavior. I for > one don't want that. > > Now if you think ISPs should start charging end sites for the privilege > of running BGP, that might fly. ISPs in the DFZ are bearing the costs of > maintaining the extra routes*, so they can justify a per-route charge, and > they actually have contracts with their customers, so they can collect. > (* Yes, other end sites in the DFZ also bear those costs, but since they > contribute routes to the table as well, and can sometimes switch to > default-only BGP, I'd argue that DFZ ISPs are the ones stuck "holding the > bag" of routing table growth.) > > > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > > don't have much preference here), but you must not be able to justify > > for larger space. This is to avoid the organization from getting a > > larger block and chopping it into smaller pieces and polluting the > > global routing table with more specifics which would get past prefix > > length filters. > > With the current ARIN policy proposal, you'd get a /48, with a /44 > reserved for growth. Would you advocate giving everyone a /44 up front > instead? Or something else? I don't have too much preference here, FWIW. > > > 3. assignments from a separate address block, set aside for PI. To > > ease strict "assignment-size only" filtering of these blocks. > > This is already a part of 2005-1, and has been a part (expressed or > implied) of every other PI proposal I've seen. > > -Scott > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From alh-ietf at tndh.net Thu Apr 20 13:42:37 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 20 Apr 2006 10:42:37 -0700 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6assignment and utilisation requirement - Last Call In-Reply-To: <200604201434.k3KEYkrW021376@cichlid.raleigh.ibm.com> Message-ID: <098a01c664a1$d08f91e0$d447190a@tndh.net> Thomas Narten wrote: > ... > Actually, the text about stateless addrconf is not quite > true. Stateless addrconf can handle any prefix length, but the real > issue is that it contains the following line: > > > > If the sum of the prefix length and interface identifier length > > does not equal 128 bits, the Prefix Information option MUST be > > ignored. > > The rules for constructing interface identifiers are specific to each > link-layer type (e.g., ethernet vs. token ring vs. ...). And in all > the individual IPv6-over-linklayer documents, the interface identifier > is specified to be 64 bits. Plus, RFC 4291 "IP Version 6 Addressing > Architecture" does say: > > > For all unicast addresses, except those that start with the binary > > value 000, Interface IDs are required to be 64 bits long and to be > > constructed in Modified EUI-64 format. > > So, if one wants to use stateless addr conf, we've effectively wired > in /64. Also note that if there is to be any hope of securing the relationship between the endpoints and the first hop router, the currently being implemented versions of RFC 3971 & 3972 have a need for 64 bits as the IID. Unfortunately people need continuous reminders that under the operational practice of that time 64 bits was determined to be 3 orders of magnitude more than necessary for the bake-off design points of 10^12 networks & 10^15 endpoints. At the start of the bubble it looked like we would need many more levels of hierarchy so we gave the whole 64 bit space to routing, then debated how much more to tack on for host identifiers. Unfortunately the conservation myopic policy community and the greedy control-mongering routing community is not satisfied with a substantially expanded version of 'more than enough' (despite collapsing back to fewer players & levels than before), and keeps wanting to encroach on the part the hosts are trying to use to improve over IPv4. ISPs keep saying they want to see improvements before they will deploy, but cry out about changing their operational practice for anything that does actually improve an aspect they don't care about. There are many aspects to what makes a protocol useful, and while the ability to globally route is an important one, it is far from the only thing that matters. With the HD ratio at .96 and site assignments at /48 we are looking at 500+ years of life expectancy under current practice. There is no way this protocol will be in use that long. People need to stop trying to optimize it for longer lifetimes, as that only reduces the ability to innovate in other areas. Tony From dlw+arin at tellme.com Thu Apr 20 13:53:00 2006 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 20 Apr 2006 10:53:00 -0700 Subject: [ppml] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BF4F@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A21BF4F@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <20060420175300.GX16281@shell01.corp.tellme.com> On Thu, Apr 20, 2006 at 10:35:01AM -0700, Davis, Terry L wrote: > I'm virtually certain that most large and/or international corporations > won't deploy IP-v6 unless they can make the service model fit their > business needs. One of the things that's really bugging me in this discussion is the criterion for determining who's an ISP (and hence qualified for PA space) versus not. Unless I'm wrong (and I'd welcome corrections), it appears the basic criterion for PA space is that your must be allocating pieces of your PA space to smaller/other organizations. The very strong implication is that you are providing ip transit for those organizations. It seems to me that there are a number of organizations out there that fit many of the characteristics of a quality ISP: highly multi-homed, BGP clue, attached to the DFZ, etc., but that don't offer transit. Without knowing actual routing policies, it seems that many large service providers that have little to know business outside of their network presence fit this category: google, amazon, ebay, etc. Perhaps there are ways to manipulate policy sufficiently to acquire PA space if you are one of this class of company, but they seem like a type of company that is unlikely to provide transit to anyone, while they have a clear business need for their own IP space. If the network *is* your business, why trust it to someone else? Sounds like a convincing need for PI space to me. As the thread has pointed out, many major corporations are now in the position of the network is the business, even if it's not their primary business. Last I checked, Boeing still sells rather large pieces of interestingly shaped metal, but I suspect their network is vital to their ongoing ability to bend said metal. The conclusion? Many companies are in the same boat as the previous class of orgs, and are also going to want PI space. My apologies for the mildly rambling stream-of-conciousness message, but the use of 'are you a tranist provider?' as the primary justification for IP space strikes me as broken. Give me my own space...I'll pay a provider to route it. If they don't want to route it, I'll take my business elsewhere. -David From memsvcs at arin.net Thu Apr 20 14:00:02 2006 From: memsvcs at arin.net (Member Services) Date: Thu, 20 Apr 2006 14:00:02 -0400 Subject: [ppml] Proposed Policy: RSA Modification Procedure Message-ID: <4447CC22.2060508@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The 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. The AC review will be conducted at their next regularly scheduled 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: RSA Modification Procedure Author: Owen DeLong Proposal Version: 1.0 Proposal type: New Policy term: Permanent Policy statement: Add a section 11. Adminstrative Practices to the NRPM as follows: 11. Administrative Practices 11.1 Changes to the Registration Services Agreement a) All changes to the registration services agreement shall be posted to PPML and discussed as any other ARIN policy change. b) The BoT shall have the authority to veto any proposed change to the RSA if doing so at the advice of counsel. c) When a change to the RSA is to take effect, ARIN shall post the new RSA on the ppml and arin-discuss lists as well as any additional lists ARIN staff feels would be appropriate (such as nanog at the time of writing) at least 30 days before said change would take effect. Rationale: It is currently being discussed on PPML that ARIN has a new policy of being able to modify the RSA without notice and suggesting that everyone review the ARIN web site every 30 days to see if it has changed. This situation is untenable. The above policy is intended to bring the RSA into compliance with other ARIN policy-related procedures. I am proposing a new section 11 to the NRPM because there really isn't a good place for it to fit in the existing sections. This is by no means intended to be a complete study of ARIN administrative practices and I would anticipate that other proposals in the future would expand and refine section 11. However, this is intended to create a place for such issues in the NRPM and to address this specific issue in that place. Timetable for implementation: Immediately upon acceptance by the BoT after last call Meeting presenter: Owen DeLong From jason.schiller at mci.com Thu Apr 20 15:12:27 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 20 Apr 2006 15:12:27 -0400 (EDT) Subject: [ppml] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060420175300.GX16281@shell01.corp.tellme.com> Message-ID: David, The problem is the routing economy as Geoff points out... Sure, if you have your own space, and you purchase transit services from a provider, then they will most likely route your space. But what about all the other transit providers in the DFZ? are you also paying them to carry your prefix as well? What about all of their down stream customers that carry a full routing table, are you going to pay them as well to cary your prefix? If there are a very limited number of routing slots in a provider's routing table then the providers are likely to desire to reserve these slots for paying customers. ___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 Thu, 20 Apr 2006, David Williamson wrote: > Date: Thu, 20 Apr 2006 10:53:00 -0700 > From: David Williamson > To: "Davis, Terry L" > Cc: ppml at arin.net > Subject: Re: [ppml] Just say *NO* to PI space -- or how to make it > lessdestructive > > On Thu, Apr 20, 2006 at 10:35:01AM -0700, Davis, Terry L wrote: > > I'm virtually certain that most large and/or international corporations > > won't deploy IP-v6 unless they can make the service model fit their > > business needs. > > One of the things that's really bugging me in this discussion is the > criterion for determining who's an ISP (and hence qualified for PA > space) versus not. > > Unless I'm wrong (and I'd welcome corrections), it appears the basic > criterion for PA space is that your must be allocating pieces of your > PA space to smaller/other organizations. The very strong implication > is that you are providing ip transit for those organizations. > > It seems to me that there are a number of organizations out there that > fit many of the characteristics of a quality ISP: highly multi-homed, > BGP clue, attached to the DFZ, etc., but that don't offer transit. > Without knowing actual routing policies, it seems that many large > service providers that have little to know business outside of their > network presence fit this category: google, amazon, ebay, etc. > > Perhaps there are ways to manipulate policy sufficiently to acquire PA > space if you are one of this class of company, but they seem like a > type of company that is unlikely to provide transit to anyone, while > they have a clear business need for their own IP space. If the network > *is* your business, why trust it to someone else? Sounds like a > convincing need for PI space to me. > > As the thread has pointed out, many major corporations are now in the > position of the network is the business, even if it's not their primary > business. Last I checked, Boeing still sells rather large pieces of > interestingly shaped metal, but I suspect their network is vital to > their ongoing ability to bend said metal. The conclusion? Many > companies are in the same boat as the previous class of orgs, and are > also going to want PI space. > > My apologies for the mildly rambling stream-of-conciousness message, > but the use of 'are you a tranist provider?' as the primary > justification for IP space strikes me as broken. Give me my own > space...I'll pay a provider to route it. If they don't want to route > it, I'll take my business elsewhere. > > -David > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Thu Apr 20 15:30:34 2006 From: randy at psg.com (Randy Bush) Date: Thu, 20 Apr 2006 14:30:34 -0500 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call References: <17473.1751.659052.317012@roam.psg.com> <200604201434.k3KEYkrW021376@cichlid.raleigh.ibm.com> Message-ID: <17479.57690.78086.363942@roam.psg.com> > So, if one wants to use stateless addr conf, we've effectively wired > in /64. we all make mistakes. so fix it. randy From jcurran at istaff.org Thu Apr 20 14:39:44 2006 From: jcurran at istaff.org (John Curran) Date: Thu, 20 Apr 2006 14:39:44 -0400 Subject: [ppml] RE: Proposed Policy: RSA Modification Procedure Message-ID: >To: ppml at arin.net >Subject: [ppml] Proposed Policy: RSA Modification Procedure Folks, The auto-renewal being subject to ARIN's then current terms and conditions has been present since the original Registration Services Agreement (RSA) in 1998. In January of 2004, the ARIN Board approved version 5 of the RSA which allows changes to be effective after posting to the ARIN website for 30 days. It has also been ARIN's practice to announce material changes to the RSA agreement to the "arin-announce" mailing list, although this is not technically required. In light of the discussion on the PPML mailing list, the ARIN Board of Trustees will take up at its next board meeting the matter of the appropriate process for changing the Registration Services Agreement, including formalizing the notice and review aspects. Thanks! /John John Curran Chair, ARIN Board of Trustees From dlw+arin at tellme.com Thu Apr 20 15:42:38 2006 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 20 Apr 2006 12:42:38 -0700 Subject: [ppml] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: References: <20060420175300.GX16281@shell01.corp.tellme.com> Message-ID: <20060420194238.GA16281@shell01.corp.tellme.com> On Thu, Apr 20, 2006 at 03:12:27PM -0400, Jason Schiller (schiller at uu.net) wrote: > But what about all the other transit providers in the DFZ? are you also > paying them to carry your prefix as well? What about all of their down > stream customers that carry a full routing table, are you going to pay > them as well to cary your prefix? I completely agree that this is a troublesome problem. I see two solutions: fix the underlying problem such that routing slots aren't a limited commodity (admittedly a hard problem), or change business practices towards more asymmetric peering arrangements (not necessarily any easier). If an ISP accepts a lot of PI routes, perhaps their peering partners should ask for a slice of that pie. It's perhaps worth noting that this problem impacts holders of PI space that are default free. My site, for example, looks like a small ISP except for one key point: we don't offer any transit. This makes me very symapthetic to the point you raise. Still, our business can't afford to get locked into space held by an organization that may or may not be well aligned with our business plans (now, or three years from now). We'll also consume that routing slot anyway, when we announce the /48 (I assume) from ISP #1. Of course, you can ignore it easier, since there is, in theory, an aggregate...but then we're dependant on ISP #1 not sucking. Ever. That's unlikely, and not acceptable. If shim6 actually worked...oh, never mind. The point I was trying to make is that the use of transit services to differentiate who should receive PA space (and therefore be allowed to consume a routing slot) seems flawed. -David From gih at apnic.net Thu Apr 20 15:55:23 2006 From: gih at apnic.net (Geoff Huston) Date: Fri, 21 Apr 2006 05:55:23 +1000 Subject: [ppml] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: References: <20060420175300.GX16281@shell01.corp.tellme.com> Message-ID: <6.2.0.14.2.20060421054902.02df2880@kahuna.telstra.net> At 05:12 AM 21/04/2006, Jason Schiller (schiller at uu.net) wrote: >The problem is the routing economy as Geoff points out... And just to be clear - the problem with the routing economy is that there is no routing economy. When there is no commonly accepted expression of constraint on consumption of a common good (in this case routing slots) then over-consumption is a highly likely outcome, which in turn tends to lead to destruction of the good (at this point it is traditional to refer to the tragedy of the commons). What we all are searching for here is the appropriate level of expression of constraint through address allocation policies. So far, its pretty clear that there is a wide diversity of opinion as to what 'appropriate' may be in this context. Geoff From william at elan.net Thu Apr 20 16:15:41 2006 From: william at elan.net (william(at)elan.net) Date: Thu, 20 Apr 2006 13:15:41 -0700 (PDT) Subject: [ppml] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <6.2.0.14.2.20060421054902.02df2880@kahuna.telstra.net> References: <20060420175300.GX16281@shell01.corp.tellme.com> <6.2.0.14.2.20060421054902.02df2880@kahuna.telstra.net> Message-ID: Geoff, why are you trying to make the explanation that complex? Its all very simple - if ISPs in other (non-ARIN) regions do not like ARIN's policy on PI allocations, those ISPs will filter these PI blocks and the result is that those who got the block would not be able to communicate with majority of IPv6 network (north america share of ipv6 is rather small) and so blocks would be mostly useless... So really we have no choice, if you want IPv6 PI assignments it can not be just North America's decision - you have to convince rest of the world that this is ok and should be accepted practice or at least tried out. [Note: By ISP above I actually mean network in general not necessarily commercial intenet service provider] On Fri, 21 Apr 2006, Geoff Huston wrote: > At 05:12 AM 21/04/2006, Jason Schiller (schiller at uu.net) wrote: >> The problem is the routing economy as Geoff points out... > > > And just to be clear - the problem with the routing economy is that there > is no routing economy. > > When there is no commonly accepted expression of constraint on > consumption of a common good (in this case routing slots) then > over-consumption is a highly likely outcome, which in turn tends to lead to > destruction of the good (at this point it is traditional to refer to the > tragedy of the commons). What we all are searching for here is the > appropriate level of expression of constraint through address allocation > policies. So far, its pretty clear that there is a wide diversity of > opinion as to what 'appropriate' may be in this context. > > Geoff > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From terry.l.davis at boeing.com Thu Apr 20 16:24:49 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Thu, 20 Apr 2006 13:24:49 -0700 Subject: [ppml] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060420175300.GX16281@shell01.corp.tellme.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BF53@XCH-NW-8V1.nw.nos.boeing.com> David > As the thread has pointed out, many major corporations are now in the > position of the network is the business, even if it's not their primary > business. Last I checked, Boeing still sells rather large pieces of > interestingly shaped metal, but I suspect their network is vital to > their ongoing ability to bend said metal. The conclusion? Many > companies are in the same boat as the previous class of orgs, and are > also going to want PI space. The network has been core to us for over decade now; everything is on it including the machines that "bend (or cut) interestingly shaped metal (or composites)". Network outages now rank only behind power outages in their business disruption costs. And now we are even including it in the aircraft so the airlines will be able to get real-time updates from the flight before it even lands on what it needs for the flight (food, fuel, service, etc), be able to re-ticket you in flight (and print the ticket), and even allow you to work or communicate while in the air (Connexion by Boeing). Take care Terry From narten at us.ibm.com Thu Apr 20 16:36:37 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 20 Apr 2006 16:36:37 -0400 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: Message from "Matthew Petach" of "Thu, 20 Apr 2006 09:59:01 PDT." <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> Message-ID: <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> On 4/14/06, Randy Bush wrote: > fwiw, after discussion with jason, i would support a more simple, direct, > and clear proposal to the same end. > > randy Question: I gather that resurrecting http://tools.ietf.org/html?draft=draft-ietf-ipv6-ula-central would also solve the technical problem at hand (since the technical requirement seems to be globally-unique address space, with no need/desire to have it be globally routable). I understand that RFC 4193 style addresses are not "unique enough" for that purpose. Would there be interest in resurrecting the ula-central document? Pros: 1) globally-unique space would be available to everyone, including end sites. I.e., for pretty much any purpose. Even during the ARIN meeting, it was pointed out that anyone with an ASN could/would presumably want something like this. Cons: 1) ARIN pretty vocally shot down the document a year or more ago, and the IETF basically decided "we don't need this so badly as to have a showdown with the ARIN community". Having said that, I (and others) still think the idea has some merit and would be willing to push on it on the IETF end, assuming we wouldn't get a repeat reaction at future meetings for our efforts... Note: AFAIK, no such reaction seemed to come out of APNIC or RIPE. 2) Does solve Jason's problem, but perhaps there is no desire to fight the larger battle at the expense of just solving the narrow/simple problem (i.e., just for ISPs). Note, however, that it will presumably take at least another 6 months (until the St. Louis meeting) to make progress on this. (Realistically, it would probably also take 6 months to get the ula-central document through the IETF, assuming there was no significant opposition from ARIN, so I'm not sure either approach is necessarily longer). 3) Would make such address space available to everyone, including all end sites, not just ISPs. Not sure this is necessarily bad, but it will result in orders of magnitude more such addresses in use. And the concerns raised in the past centered around the fear that ISPs would be asked/forced to route them... I know that there is at least one person willing to resurrect the ula-central document, but I (personally) don't want to invest cycles in it if it's going to get a frosty reception in ARIN again. Been there, done that. Thomas From pekkas at netcore.fi Thu Apr 20 16:44:42 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 23:44:42 +0300 (EEST) Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <054601c66496$60f6b210$3712fea9@ssprunk> References: <054601c66496$60f6b210$3712fea9@ssprunk> Message-ID: On Thu, 20 Apr 2006, Stephen Sprunk wrote: > I think that the multihoming requirement will be enough to keep the > number of assignments reasonable; if you look at the actual number > of non-transit ASNs in the v4 table, it's not all that large. If we > assume one PIv6 prefix per non-transit ASN, which is the goal, we're > looking at under 10k routes from the ARIN region. (Actually, the number is somewhere between 15k and 20k but that's beside the point.) The upper limit is around the number of AS numbers, and if it's expanded to 32 bits, at least I start to feel uncomforable... "Umm.. are we sure 64K folks playing around at DFZ isn't enough??? we want 4B instead...????" Remember, it's easy and cheap to have a multihoming setup with two DSL lines... >> That is, ARIN has every right to require, for example, that everyone >> getting a prefix is (for instance) a member of ARIN, and charging for >> the membership should be OK. > > I'd want a lawyer to sign off on it. You're talking about > deliberately charging an excessive fee to make it more difficult for > smaller companies to compete with larger ones. That has the > appearance of an industry cartel creating artificial barriers to > lock their smaller competitors out of the market, and the FTC > generally doesn't like that. Come on, arguing that 1K or even 5K is an "excessive fee" for PI prefixes in the context of reliable multihoming setup and services provided seems a bit absurd. I'd agree that if the charge was 100K per year, this could be considered locking out smaller competitors, but (say) 1K is nothing -- that's less than 100 bucks a month! You might even consider a payment like 1K or 2K fair: small ISPs which get exactly the same resources have to pay such in their membership fees. Obviously the end-sites should pay at least the same if they consume the same resources.. >> setting a foundation for multihoming research to actually SOLVE this >> problem, etc.etc. > > In theory, we already have a group tasked with that: the IETF. Are you > proposing that RIRs start developing protocols outside the IETF? Or funding > people to work full-time in the IETF on problems pertinent to RIRs? Again, > this is a slippery slope and distracts from the RIRs' purpose. I said 'research', not 'engineering'. The IETF isn't the right vessel for research, though IETF could maybe be consulted on it. >> I wouldn't object to reserving a /44 just in case, but make no >> provisions (at this point) for applying more. If someone needs more >> than /48, it needs to justify another one, and get a separate /48 >> (with its own reserved /44). > > So instead of giving an org a /47, which _could_ be advertised as a single > route, you'd prefer to give them two /48s, which _must_ be advertised as two > routes? That seems to increase routing table pollution, not reduce it. Not necessarily. Doing so would hopefully ensure that it'll be *more* difficult to justify for more than a /48 especially if you have to pay for the extra too (hence less pollution). I.e., we'd need to figure out we have sufficiently strict criteria. > Also, what's the point of reserving a /44, or worse multiple /44s, if we're > only going to let people use a /48? That seems to defeat the purpose of > having a reserved block. As I said, I wouldn't object to reserving a /44 under those conditions, but I wouldn't require reservation either. One reason for reserving is that we could have the option of changing the policy later if we become wiser (or dumber) and decide that maybe we'll want to be able to deal out aggregatable chunks after all, regardless of the more specific crap that's filling the routing tables right now. -- 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 dlw+arin at tellme.com Thu Apr 20 17:00:52 2006 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 20 Apr 2006 14:00:52 -0700 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: <054601c66496$60f6b210$3712fea9@ssprunk> Message-ID: <20060420210052.GD16281@shell01.corp.tellme.com> On Thu, Apr 20, 2006 at 11:44:42PM +0300, Pekka Savola wrote: > Remember, it's easy and cheap to have a multihoming setup with two DSL > lines... Sorry, I don't buy this argument. Organizations with enough clue to successfully multihome will generally have enough clue to get "real" pipes. The only excpetion to this is individuals (like many of the folsk on this list), and they'll have a hard time justifying the space usage. I'll agree it's possible within the current policy proposals and existing policy, but it's also possible that there will be a 7.5 magnitude earthquake in San Francisco today. Neither possibility has me worried at the moment. -David (hoping the ground doesn't start moving now. :) From dlw+arin at tellme.com Thu Apr 20 17:04:39 2006 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 20 Apr 2006 14:04:39 -0700 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> References: <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> Message-ID: <20060420210439.GE16281@shell01.corp.tellme.com> On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: > Would there be interest in resurrecting the ula-central document? Speaking only for me, yes. It would seem mildly clever to put the AS number somewhere in the network number (pick an appropriate range of bits in the prefix), and then hand out the appropriate /48 implicitly with any AS received from an RIR (including legacy AS holders, obviously). I'm completely in favor of this idea. On the other hand, if the IETF can't quite get this thing wrapped up, I'd be in favor of a simplified 2006-2. -David From narten at us.ibm.com Thu Apr 20 17:18:00 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 20 Apr 2006 17:18:00 -0400 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: Message from David Williamson of "Thu, 20 Apr 2006 14:04:39 PDT." <20060420210439.GE16281@shell01.corp.tellme.com> Message-ID: <200604202118.k3KLI0Gc029771@cichlid.raleigh.ibm.com> David Williamson writes: > On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: > > Would there be interest in resurrecting the ula-central document? > Speaking only for me, yes. > It would seem mildly clever to put the AS number somewhere in the > network number (pick an appropriate range of bits in the prefix), and > then hand out the appropriate /48 implicitly with any AS received from > an RIR (including legacy AS holders, obviously). OK, I'll bite. The original ULA Central approach just called for a single way of getting ULA assignments. I.e., just one "registry". The registry would be responsible for assigning unique values for the "global ID" field, which is 40 bits. Discussions at the time assumed/implied that the RIRs would play this role. During the discussion last week, it occurred to me that it might make sense to actually have a small number of different kinds of "ula central" addresses (each still globally unique and guaranteed not to collide with those allocated by different means). That is, have the "global ID" field consist of a (say?) 4 bit "address type", followed by a (say?) 36 bit "global ID" field. One of the "address types" could indicate (as you suggest) "ASN number", in which case the "global ID" field would just contain an ASN number. Voila. All ISPs already have one. Same could be done for end sites, for which IANA already maintains a registry for PENs (Private Enterprise Numbers). Some 25K of them have already been assigned, and they are trivial to obtain. Voila, we've already grandfathered in a huge number of end sites. (I'm not sure now how much the above was ever discussed in the discussions leading up to the ULA central document, but I'd be in favor of considering such an approach.) Thomas From william at elan.net Thu Apr 20 17:20:30 2006 From: william at elan.net (william(at)elan.net) Date: Thu, 20 Apr 2006 14:20:30 -0700 (PDT) Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <20060420210439.GE16281@shell01.corp.tellme.com> References: <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> <20060420210439.GE16281@shell01.corp.tellme.com> Message-ID: On Thu, 20 Apr 2006, David Williamson wrote: > On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: >> Would there be interest in resurrecting the ula-central document? > > Speaking only for me, yes. > > It would seem mildly clever to put the AS number somewhere in the > network number (pick an appropriate range of bits in the prefix), and > then hand out the appropriate /48 implicitly with any AS received from > an RIR (including legacy AS holders, obviously). I'm also in favor of this. In fact my view is that we really don't need ip allocations if we engineered ipv6 properly. We could have BGP table where it is entirely one asn announcing routes to other ASNs and and ip addresses are composed of global network part that is ASN, local network part that is entirely dependent on how each ASN wants to set it up (and it would be cool if local network part was 32-bit in size so you could just use existing ipv4 numbers for it without any changes) and then additional bits for local device specific address (and in my view 64bit is way too much). We could probably try it as a global experiment with existing ipv6 with setup like: 8 bits - IPv6 ASN experiment global prefix 32 bits - ASN number 24 bits - local network address if possible last 24 bits of ipv4 Last one (24 bit local) would not be enough to fully map ipv4 address for those who have ip addresses from different /8 ipv4 blocks currently. (unless we abandon 64 bit boundary for local device id...) -- William Leibzon Elan Networks william at elan.net From kloch at hotnic.net Thu Apr 20 17:30:21 2006 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 20 Apr 2006 17:30:21 -0400 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised In-Reply-To: <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> References: <443FFFC6.1060208@arin.net> <17472.692.685697.785280@roam.psg.com> <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> Message-ID: <4447FD6D.5070409@hotnic.net> Matthew Petach wrote: > On 4/14/06, *Randy Bush* > wrote: > > fwiw, after discussion with jason, i would support a more simple, > direct, > and clear proposal to the same end. > > randy > > > We would likewise vote in favour of the proposal were it to be > tightened up and clarified more; currently, the model of burning > a /32 for router loopbacks seems overly wasteful of address space; > being able to use a /48 for this would be a far better choice. Would a /96 be sufficient if the intended use is for /126-/128's? That might also reduce the concern about them being inadvertantly announced. - Kevin From brian.knight at us.mizuho-sc.com Thu Apr 20 18:35:23 2006 From: brian.knight at us.mizuho-sc.com (brian.knight at us.mizuho-sc.com) Date: Thu, 20 Apr 2006 17:35:23 -0500 Subject: [ppml] IPv6 PI space for addressing Message-ID: <10793F3BC5C33C489C69893C14242C0904C6F27D@JUPITER> I've been watching the debate over IPv6 PI space for well over a year (mostly on NANOG), and one thing stands out to me. Many moons ago, if an organization intended to run IPv4 in their network, they could secure an IPv4 allocation even if they did not intend to route that prefix over the Internet. I believe address depletion is still a valid concern with IPv6, and the draft policies do address this concern. However, I believe the restrictions on IPv6 PI space should recognize the need for such space outside of the Internet routing table. I'm part of a financial organization that deals in futures and other securities. We do not presently qualify for IPv4 PI space - our network is simply not large enough. However, we could benefit greatly from PI space. Without going into too much detail, our network has two border zones: one to the Internet and one to our business partners. Our partners include financial exchanges, software vendors, and our customers. We use PA space for our Internet addressing, and RFC1918 for nearly all B2B connections. It's quite challenging for us and for our business partners to manage our routing. We use NAT at nearly every entry and exit point, sometimes forcing us to buy extra equipment just to support that function. If we could reserve PI space and deploy that throughout our network, rather than more-dynamic PA space or some non-unique range, it would obviate the need for NAT within our more complex border zone, and eliminate the problems of readdressing there. We wouldn't attempt to announce this prefix within the global routing table. We would simply translate our internal PI addresses to the PA block our ISP will have provided. In fact, as I envision our network 10 years from now, the only need for NAT would be at the Internet border of our network, where we'll be translating our PI space into PA space. :) Being tied to PA space within our internal net would not be a good thing for us. Yes, DNS makes transitions much easier, but address-centric issues remain. We would need to coordinate with every one of our business partners to have them update their routing for whichever private subnets we've chosen to route. (That, or we would adjust NAT definitions for each partner.) We'd also have to adjust our IPSec tunnels, which means more coordination. We may also need to renumber point-to-point links, which means more coordination. We have all the pain of renumbering should we choose to change ISP's. A change in one zone would require a change in the other. Non-unique addressing has all the problems of today: NAT, possible overlapping ranges, renumbering, etc. This is the least desirable option of all three addressing schemes, IMO. Couldn't the draft policies / amendments under consideration recognize the need for PI space outside of the realm of Internet routing? Perhaps a policy could be crafted that allows allocations for entities which have permanent (leased-line, IPSec site-to-site VPN, or equivalent), routed connectivity to more than, say, 15-20 separate non-ISP entities. Couldn't ARIN offer that to my company, possibly with the caveat that the allocation will NOT be permitted in the global routing table? I have to say that it seems ARIN and the other RIRs are getting co-opted into policing the routing table on behalf of ISP's. And maybe that's the best way to do it if any other solution would result in massively ugly peering battles. I admit, I don't know the ISP business very well. But if I can leverage IPv6 PI space for my company's network, should we be denied because of an unrelated issue? At the moment, this would be the only driver I can think of for my company to adopt IPv6 quickly. Even then, I would depend on other organizations to enable IPv6 on their networks before the benefit could be fully realized. -Brian Knight Sr. Network Engineer Mizuho Securities USA http://www.mizuho-sc.com/ * Please note that I do not speak for my employer - only for myself. From alh-ietf at tndh.net Thu Apr 20 19:05:22 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 20 Apr 2006 16:05:22 -0700 Subject: [ppml] IPv6 PI space for addressing In-Reply-To: <10793F3BC5C33C489C69893C14242C0904C6F27D@JUPITER> Message-ID: <0a2c01c664ce$e6f93490$d447190a@tndh.net> brian.knight at us.mizuho-sc.com wrote: > I've been watching the debate over IPv6 PI space for well over a year > (mostly on NANOG), and one thing stands out to me. Many moons ago, if an > organization intended to run IPv4 in their network, they could secure an > IPv4 allocation even if they did not intend to route that prefix over the > Internet. > > I believe address depletion is still a valid concern with IPv6, and the > draft policies do address this concern. However, I believe the > restrictions > on IPv6 PI space should recognize the need for such space outside of the > Internet routing table. > > I'm part of a financial organization that deals in futures and other > securities. We do not presently qualify for IPv4 PI space - our network > is > simply not large enough. However, we could benefit greatly from PI space. > Without going into too much detail, our network has two border zones: one > to > the Internet and one to our business partners. Our partners include > financial exchanges, software vendors, and our customers. We use PA space > for our Internet addressing, and RFC1918 for nearly all B2B connections. > It's quite challenging for us and for our business partners to manage our > routing. We use NAT at nearly every entry and exit point, sometimes > forcing > us to buy extra equipment just to support that function. > > If we could reserve PI space and deploy that throughout our network, > rather > than more-dynamic PA space or some non-unique range, it would obviate the > need for NAT within our more complex border zone, and eliminate the > problems > of readdressing there. We wouldn't attempt to announce this prefix within > the global routing table. We would simply translate our internal PI > addresses to the PA block our ISP will have provided. In fact, as I > envision our network 10 years from now, the only need for NAT would be at > the Internet border of our network, where we'll be translating our PI > space > into PA space. :) > > Being tied to PA space within our internal net would not be a good thing > for > us. Yes, DNS makes transitions much easier, but address-centric issues > remain. We would need to coordinate with every one of our business > partners > to have them update their routing for whichever private subnets we've > chosen > to route. (That, or we would adjust NAT definitions for each partner.) > We'd also have to adjust our IPSec tunnels, which means more coordination. > We may also need to renumber point-to-point links, which means more > coordination. We have all the pain of renumbering should we choose to > change ISP's. A change in one zone would require a change in the other. > > Non-unique addressing has all the problems of today: NAT, possible > overlapping ranges, renumbering, etc. This is the least desirable option > of > all three addressing schemes, IMO. > > Couldn't the draft policies / amendments under consideration recognize the > need for PI space outside of the realm of Internet routing? Perhaps a > policy could be crafted that allows allocations for entities which have > permanent (leased-line, IPSec site-to-site VPN, or equivalent), routed > connectivity to more than, say, 15-20 separate non-ISP entities. Couldn't > ARIN offer that to my company, possibly with the caveat that the > allocation > will NOT be permitted in the global routing table? > > I have to say that it seems ARIN and the other RIRs are getting co-opted > into policing the routing table on behalf of ISP's. And maybe that's the > best way to do it if any other solution would result in massively ugly > peering battles. I admit, I don't know the ISP business very well. But > if > I can leverage IPv6 PI space for my company's network, should we be denied > because of an unrelated issue? > > At the moment, this would be the only driver I can think of for my company > to adopt IPv6 quickly. Even then, I would depend on other organizations > to > enable IPv6 on their networks before the benefit could be fully realized. You mix a couple of requirements here. For the 'never intends to route it' part, you want to look at the thread Thomas Narten started: Resurrecting ULA Central... Short of that, RFC 4193 will likely meet your needs. For the 'to be routed' part you are talking about PI space. All uses of address space are valid, and yes the ISPs are leaning on the RIRs to police because they know the business side of their house will not refuse to take the customer's money so they will have to route whatever the customer has. They see the only way out as creating policies that deny space. Fortunately this is a problem of their own making as the real issue is the ego driven need to 'know it all'. The routing protocols don't require passing around a full list everywhere, but operational practice does that because each ISP has to be 'a big player'. Several of us are talking about ways to structure the PI space so that if the disaster scenario ever becomes real there will be a way to contain and partition the problem. Your needs are as valid as any other, and what the policy process needs is more input from the enterprise network managers like yourself. Tell every company you deal with that now is the time to weigh in and make sure they are not locked out by policies that favor the ISP at the expense of their customers. Tony From ipgoddess at gmail.com Thu Apr 20 19:10:33 2006 From: ipgoddess at gmail.com (Stacy Taylor) Date: Thu, 20 Apr 2006 16:10:33 -0700 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised In-Reply-To: <17472.692.685697.785280@roam.psg.com> References: <443FFFC6.1060208@arin.net> <17472.692.685697.785280@roam.psg.com> Message-ID: <1c16a4870604201610i11befa50s91da3e1e8ece72ad@mail.gmail.com> Hi Everyone! Would the omission of the 6.10.1 and 6.10.2, sections, (largely editorial sections to begin with), from this policy proposal be classified as clarification, or a step in that direction? 6.10.3 seems to me to be clear on its own. Thanks! /Stacy On 4/14/06, Randy Bush wrote: > fwiw, after discussion with jason, i would support a more simple, direct, > and clear proposal to the same end. > > randy > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From pesherb at yahoo.com Thu Apr 20 21:28:23 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Thu, 20 Apr 2006 18:28:23 -0700 (PDT) Subject: [ppml] IPv6 PI space for addressing In-Reply-To: <0a2c01c664ce$e6f93490$d447190a@tndh.net> Message-ID: <20060421012823.92449.qmail@web54706.mail.yahoo.com> > more input from the enterprise network managers like yourself. Tell every > company you deal with that now is the time to weigh in and make sure they > are not locked out by policies that favor the ISP at the expense of their > customers. Does "rough consensus" still works when in actuality it looks like IETF needs support of customers who may not even be aware of IPv6 benefits to counterweight economic interests of ISPs? Peter --- Tony Hain wrote: > brian.knight at us.mizuho-sc.com wrote: > > I've been watching the debate over IPv6 PI space for well over a year > > (mostly on NANOG), and one thing stands out to me. Many moons ago, if an > > organization intended to run IPv4 in their network, they could secure an > > IPv4 allocation even if they did not intend to route that prefix over the > > Internet. > > > > I believe address depletion is still a valid concern with IPv6, and the > > draft policies do address this concern. However, I believe the > > restrictions > > on IPv6 PI space should recognize the need for such space outside of the > > Internet routing table. > > > > I'm part of a financial organization that deals in futures and other > > securities. We do not presently qualify for IPv4 PI space - our network > > is > > simply not large enough. However, we could benefit greatly from PI space. > > Without going into too much detail, our network has two border zones: one > > to > > the Internet and one to our business partners. Our partners include > > financial exchanges, software vendors, and our customers. We use PA space > > for our Internet addressing, and RFC1918 for nearly all B2B connections. > > It's quite challenging for us and for our business partners to manage our > > routing. We use NAT at nearly every entry and exit point, sometimes > > forcing > > us to buy extra equipment just to support that function. > > > > If we could reserve PI space and deploy that throughout our network, > > rather > > than more-dynamic PA space or some non-unique range, it would obviate the > > need for NAT within our more complex border zone, and eliminate the > > problems > > of readdressing there. We wouldn't attempt to announce this prefix within > > the global routing table. We would simply translate our internal PI > > addresses to the PA block our ISP will have provided. In fact, as I > > envision our network 10 years from now, the only need for NAT would be at > > the Internet border of our network, where we'll be translating our PI > > space > > into PA space. :) > > > > Being tied to PA space within our internal net would not be a good thing > > for > > us. Yes, DNS makes transitions much easier, but address-centric issues > > remain. We would need to coordinate with every one of our business > > partners > > to have them update their routing for whichever private subnets we've > > chosen > > to route. (That, or we would adjust NAT definitions for each partner.) > > We'd also have to adjust our IPSec tunnels, which means more coordination. > > We may also need to renumber point-to-point links, which means more > > coordination. We have all the pain of renumbering should we choose to > > change ISP's. A change in one zone would require a change in the other. > > > > Non-unique addressing has all the problems of today: NAT, possible > > overlapping ranges, renumbering, etc. This is the least desirable option > > of > > all three addressing schemes, IMO. > > > > Couldn't the draft policies / amendments under consideration recognize the > > need for PI space outside of the realm of Internet routing? Perhaps a > > policy could be crafted that allows allocations for entities which have > > permanent (leased-line, IPSec site-to-site VPN, or equivalent), routed > > connectivity to more than, say, 15-20 separate non-ISP entities. Couldn't > > ARIN offer that to my company, possibly with the caveat that the > > allocation > > will NOT be permitted in the global routing table? > > > > I have to say that it seems ARIN and the other RIRs are getting co-opted > > into policing the routing table on behalf of ISP's. And maybe that's the > > best way to do it if any other solution would result in massively ugly > > peering battles. I admit, I don't know the ISP business very well. But > > if > > I can leverage IPv6 PI space for my company's network, should we be denied > > because of an unrelated issue? > > > > At the moment, this would be the only driver I can think of for my company > > to adopt IPv6 quickly. Even then, I would depend on other organizations > > to > > enable IPv6 on their networks before the benefit could be fully realized. > > You mix a couple of requirements here. For the 'never intends to route it' > part, you want to look at the thread Thomas Narten started: Resurrecting ULA > Central... Short of that, RFC 4193 will likely meet your needs. For the 'to > be routed' part you are talking about PI space. > > All uses of address space are valid, and yes the ISPs are leaning on the > RIRs to police because they know the business side of their house will not > refuse to take the customer's money so they will have to route whatever the > customer has. They see the only way out as creating policies that deny > space. Fortunately this is a problem of their own making as the real issue > is the ego driven need to 'know it all'. > > The routing protocols don't require passing around a full list everywhere, > but operational practice does that because each ISP has to be 'a big > player'. Several of us are talking about ways to structure the PI space so > that if the disaster scenario ever becomes real there will be a way to > contain and partition the problem. > > Your needs are as valid as any other, and what the policy process needs is > more input from the enterprise network managers like yourself. Tell every > company you deal with that now is the time to weigh in and make sure they > are not locked out by policies that favor the ISP at the expense of their > customers. > > Tony > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From stephen at sprunk.org Thu Apr 20 22:39:44 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 20 Apr 2006 21:39:44 -0500 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive References: <054601c66496$60f6b210$3712fea9@ssprunk> Message-ID: <088201c664ec$d991ac60$3712fea9@ssprunk> Thus spake "Pekka Savola" > On Thu, 20 Apr 2006, Stephen Sprunk wrote: >> I think that the multihoming requirement will be enough to keep the >> number of assignments reasonable; if you look at the actual number of >> non-transit ASNs in the v4 table, it's not all that large. If we assume >> one PIv6 prefix per non-transit ASN, which is the goal, we're looking at >> under 10k routes from the ARIN region. > > (Actually, the number is somewhere between 15k and 20k but that's beside > the point.) ARIN Region origin ASes present in the Internet Routing Table: 10637 ... ARIN Region transit ASes present in the Internet Routing Table: 986 To me, that says we have 9651 non-transit ASes in ARIN-land today. Now, if every one of those ASes got an assignment under 2005-1, we'd kick up the size of the v6 routing table to 14 times its current size -- but it'd still be only 1/18th of the current v4 table. Where's the problem? > The upper limit is around the number of AS numbers, and if it's expanded > to 32 bits, at least I start to feel uncomforable... "Umm.. are we sure > 64K folks playing around at DFZ isn't enough??? we want 4B instead...????" There's at least one router vendor that claims their box can do 1M routes today; Moore's Law says in 18 years they'll be able to do 4B ASes with one prefix each. I'm pretty confident we won't run into that particular limit before we run out of networks to multihome, at least not with the proposal on the table today. > Remember, it's easy and cheap to have a multihoming setup with two DSL > lines... That loophole in the definition of multihoming needs to be fixed. For that matter, ARIN told me offlist that two IP-in-IP tunnels over a single physical link counts as multihoming... Sheesh. OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two pipes or tunnels), and there's not all that many companies doing it. It's not growing much either. The doors are already wide open for a land rush and nobody is taking ARIN up on it. Why does everyone assume it'll happen with v6 if it's not happening with v4, which _is_ useful today? >>> setting a foundation for multihoming research to actually SOLVE this >>> problem, etc.etc. >> >> In theory, we already have a group tasked with that: the IETF. Are >> you proposing that RIRs start developing protocols outside the IETF? Or >> funding people to work full-time in the IETF on problems pertinent >> to RIRs? Again, this is a slippery slope and distracts from the RIRs' >> purpose. > > I said 'research', not 'engineering'. The IETF isn't the right vessel for > research, though IETF could maybe be consulted on it. s/IETF/IRTF/ then. The RRG is expecting to have results sometime between 2007 and 2011. That's probably sufficient, if they actually deliver something useful. Still, the RIRs' job is not research, it is stewardship of address space and serving its members. >>> I wouldn't object to reserving a /44 just in case, but make no >>> provisions (at this point) for applying more. If someone needs more >>> than /48, it needs to justify another one, and get a separate /48 >>> (with its own reserved /44). >> >> So instead of giving an org a /47, which _could_ be advertised as a >> single route, you'd prefer to give them two /48s, which _must_ be >> advertised as two routes? That seems to increase routing table >> pollution, not reduce it. > > Not necessarily. Doing so would hopefully ensure that it'll be *more* > difficult to justify for more than a /48 especially if you have to pay for > the extra too (hence less pollution). I.e., we'd need to figure out we > have sufficiently strict criteria. That just seems backwards to me. If a site _can_ justify more than a /48 under whatever the policy is, why would we want to assign two separate blocks that can't be aggregated into a single route? >> Also, what's the point of reserving a /44, or worse multiple /44s, if >> we're only going to let people use a /48? That seems to defeat the >> purpose of having a reserved block. > > As I said, I wouldn't object to reserving a /44 under those conditions, > but I wouldn't require reservation either. One reason for reserving is > that we could have the option of changing the policy later if we become > wiser (or dumber) and decide that maybe we'll want to be able to deal out > aggregatable chunks after all, regardless of the more specific crap that's > filling the routing tables right now. If we're going to reserve, we ought to assign supernets within that block as justified by the org. If they deaggregate, so be it, but at least there's the chance they won't. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From dr at cluenet.de Thu Apr 20 23:23:49 2006 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 21 Apr 2006 05:23:49 +0200 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: <054601c66496$60f6b210$3712fea9@ssprunk> Message-ID: <20060421032349.GA20024@srv01.cluenet.de> On Thu, 20 Apr 2006 18:28:41 +0300, you wrote: > Larger end-sites already have 10-20k+ annual budget (most have much, > much larger than that): caused by CAPEX by getting at least two > routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and > salaries of network engineering staff. On Thu, Apr 20, 2006 at 11:44:42PM +0300, Pekka Savola wrote: > Remember, it's easy and cheap to have a multihoming setup with two DSL > lines... Could you finally make up your mind? First, your argument was that multihoming is expensive anyway, so shelling out another couple thousand of EUR/USD/whatever doesn't make a difference - just to keep the clueless bottom-feeders out. Now you say it's totally cheap to multihome. You're contradicting yourself. If you want to contain /senseless/ DFZ pollution, start with the ISPs. Just take a look at CIDR report. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From randy at psg.com Fri Apr 21 01:53:02 2006 From: randy at psg.com (Randy Bush) Date: Fri, 21 Apr 2006 00:53:02 -0500 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] References: <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> <20060420210439.GE16281@shell01.corp.tellme.com> Message-ID: <17480.29502.386014.166478@roam.psg.com> > It would seem mildly clever to put the AS number somewhere in the > network number (pick an appropriate range of bits in the prefix) is this another binding of locators to identifiers? randy From randy at psg.com Fri Apr 21 02:27:24 2006 From: randy at psg.com (Randy Bush) Date: Fri, 21 Apr 2006 09:27:24 +0300 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] References: <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> Message-ID: <17480.31564.910183.899582@roam.psg.com> could folk please explain how these various suggestions differ from 1918 on the dimensions which seem operationally annoying today? e.g. o leakage of packets with source of unreachable addresses o dns entries with unreachables on the rhs o traceroutes through infrastructure o dns dynupd for unreachables we have a plenty of history that "should not" in an rfc does not help much. is there something we can do to not continue the pain while getting some benefit? randy From pekkas at netcore.fi Fri Apr 21 05:01:51 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 21 Apr 2006 12:01:51 +0300 (EEST) Subject: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <20060421032349.GA20024@srv01.cluenet.de> References: <054601c66496$60f6b210$3712fea9@ssprunk> <20060421032349.GA20024@srv01.cluenet.de> Message-ID: On Fri, 21 Apr 2006, Daniel Roesen wrote: > On Thu, 20 Apr 2006 18:28:41 +0300, you wrote: >> Larger end-sites already have 10-20k+ annual budget (most have much, >> much larger than that): caused by CAPEX by getting at least two >> routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and >> salaries of network engineering staff. > > On Thu, Apr 20, 2006 at 11:44:42PM +0300, Pekka Savola wrote: >> Remember, it's easy and cheap to have a multihoming setup with two DSL >> lines... > > Could you finally make up your mind? First, your argument was that > multihoming is expensive anyway, so shelling out another couple thousand > of EUR/USD/whatever doesn't make a difference - just to keep the > clueless bottom-feeders out. Now you say it's totally cheap to multihome. > > You're contradicting yourself. You took the comments out of context. The former describes that _real_ multihoming is expensive, the latter describes that you could obtain "multihoming" very easily. The point is that we definitely shouldn't want to assign PI to the organizations in the latter category. -- 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 owen at delong.com Fri Apr 21 05:12:43 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Apr 2006 02:12:43 -0700 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> References: <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> Message-ID: --On April 20, 2006 4:36:37 PM -0400 Thomas Narten wrote: > On 4/14/06, Randy Bush wrote: > >> fwiw, after discussion with jason, i would support a more simple, direct, >> and clear proposal to the same end. >> >> randy > > Question: > > I gather that resurrecting > > http://tools.ietf.org/html?draft=draft-ietf-ipv6-ula-central > > would also solve the technical problem at hand (since the technical > requirement seems to be globally-unique address space, with no > need/desire to have it be globally routable). > > I understand that RFC 4193 style addresses are not "unique enough" for > that purpose. > > Would there be interest in resurrecting the ula-central document? > > Pros: > > 1) globally-unique space would be available to everyone, including end > sites. I.e., for pretty much any purpose. Even during the ARIN > meeting, it was pointed out that anyone with an ASN could/would > presumably want something like this. > > Cons: > > 1) ARIN pretty vocally shot down the document a year or more ago, and > the IETF basically decided "we don't need this so badly as to have > a showdown with the ARIN community". Having said that, I (and > others) still think the idea has some merit and would be willing to > push on it on the IETF end, assuming we wouldn't get a repeat > reaction at future meetings for our efforts... > > Note: AFAIK, no such reaction seemed to come out of APNIC or RIPE. > I remember most of the ARIN opposition to this being opposition to ULA-Random which, unfortunately, was preserved, and, concern that somehow ULA-Central would end up getting routed if there was no PI policy. Since a PI policy appears to be imminent, I would not have nearly such an objection to ULA-central now. > 2) Does solve Jason's problem, but perhaps there is no desire to fight > the larger battle at the expense of just solving the narrow/simple > problem (i.e., just for ISPs). Note, however, that it will > presumably take at least another 6 months (until the St. Louis > meeting) to make progress on this. (Realistically, it would > probably also take 6 months to get the ula-central document through > the IETF, assuming there was no significant opposition from ARIN, > so I'm not sure either approach is necessarily longer). > I think it is 5.999999999999999999998 of one 5.999999999999999999 of the other. > 3) Would make such address space available to everyone, including all > end sites, not just ISPs. Not sure this is necessarily bad, but it > will result in orders of magnitude more such addresses in use. And > the concerns raised in the past centered around the fear that ISPs > would be asked/forced to route them... > Given the ability for sites to get PI space (assuming 2005-1 moves from last call to policy), I don't see this as being the major issue I perceived it to be when ULA-central was proposed and it looked like PI was impossible. > I know that there is at least one person willing to resurrect the > ula-central document, but I (personally) don't want to invest cycles > in it if it's going to get a frosty reception in ARIN again. Been > there, done that. > As one of the coldest shoulders presented to ULA (in general), I can say that assuming 2005-1 does not go down in some last-ditch set of unanticipated flames, I would not oppose resurrection of ULA-central because I believe the potential for economic-based abuse is much less now. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jeroen at unfix.org Fri Apr 21 05:22:04 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 21 Apr 2006 11:22:04 +0200 Subject: [ppml] IPv6 PI for all organisations who already have IPv4 PI (Was: Resurrecting ULA Central ...) In-Reply-To: References: <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> <20060420210439.GE16281@shell01.corp.tellme.com> Message-ID: <1145611324.15716.12.camel@firenze.zurich.ibm.com> On Thu, 2006-04-20 at 14:20 -0700, william(at)elan.net wrote: [..] > We could probably try it as a global experiment with existing ipv6 > with setup like: > 8 bits - IPv6 ASN experiment global prefix > 32 bits - ASN number > 24 bits - local network address if possible last 24 bits of ipv4 There is something which already exists for all of this: 6to4: See RFC3056, http://www.ietf.org/rfc/rfc3056.txt This will give you, based on your IPv4 address space that you have a very nice IPv6 /48 per IPv4 /32 that you already have. Thus if you have say 192.0.2.1/24 (IPv4 TestNet ;) then you automatically have: 192 => 0xc0 0 => 0x00 2 => 0x02 1 => 0x01 Thus: 2002:c000:0201::/48 But it is a /24, thus it is much bigger (32-24 = 8): Making: 2002:c000:0201::/40 Which you are officially allowed to use when you 'own' the IPv4 /24. Reverse delegations are also possible btw. There is one issue though: The current RFC3056 section 5.2.2 specifies that: 8<----------------------------- On its native IPv6 interface, the relay router MUST advertise a route to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on that interface. Routing policy within the native IPv6 routing domain determines the scope of that advertisement, thereby limiting the visibility of the relay router in that domain. ----------------------------->8 6to4 thus solves the "I want globally unique address space" question. It does not solve the "I require a routing slot". Though of course, you could just announce a more specific and see who accepts it. Or announce it and convince people to start accepting it. If thou have cash it willeth beeth accepteth ;) PS: Two side notes: 1) Do to the way that 6to4 functions it is nearly impossible to easily debug any connectivity problems as one can't know the backpath it travels as BGP doesn't tell you which 6to4 relay is being used. 2) Address selection is a lot of fun. If you have a 2001::/16 prefix and a 6to4 address on the same host, then 2003::/16 destination will use the 6to4 source, though 2003::/16 should be 'native' and thus most likely routes better from the 2001::/16 interface. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From stephen at sprunk.org Fri Apr 21 06:19:31 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 21 Apr 2006 05:19:31 -0500 Subject: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive References: <054601c66496$60f6b210$3712fea9@ssprunk><20060421032349.GA20024@srv01.cluenet.de> Message-ID: <0b4301c6652d$15b1def0$3712fea9@ssprunk> Thus spake "Pekka Savola" > On Fri, 21 Apr 2006, Daniel Roesen wrote: >> On Thu, Apr 20, 2006 at 11:44:42PM +0300, Pekka Savola wrote: >>> Remember, it's easy and cheap to have a multihoming setup with >>> two DSL lines... ARIN has replied to me privately that two IPv6 tunnels over the same physical link count as "multihoming"; another PPML poster has told me privately he's actually gotten an ASN that way. IMHO this needs to be corrected, but it doesn't appear to be abused except out of novelty, so it's not a dire emergency. >> Could you finally make up your mind? First, your argument was that >> multihoming is expensive anyway, so shelling out another couple >> thousand of EUR/USD/whatever doesn't make a difference - just to >> keep the clueless bottom-feeders out. Now you say it's totally >> cheap to multihome. >> >> You're contradicting yourself. > > You took the comments out of context. The former describes that > _real_ multihoming is expensive, the latter describes that you could > obtain "multihoming" very easily. The point is that we definitely > shouldn't want to assign PI to the organizations in the latter > category. My reading of the proposal is that it would allow anyone who is multihomed to get a PIv6 /48 if they can demonstrate the ability to utilize 256 addresses immediately and 512 addresses within one year, or 1024 and 2048 addresses, respectively, if not multihomed. The address counts appear to be reasonable at first blush. They're high enough to stop residential and SOHO users, but low enough for nearly any shop with BGP clue to get a block. Do remember that only a few hundred direct assignments have been made under the PIv4 policy, so apparently it's not _too_ low or we'd have seen a land rush already. As far as fees, if the org already has IPv4 space of some sort, the PIv6 assignment will presumably be free through 31 Dec 07 like PAv6 assignments and USD1250/yr after that. The idea of charging thousands of dollars more to discourage PIv6 applications is not in line with existing fee schedules and rather pointless since folks can apparently claim to be LIRs without much difficulty and pay USD2250/yr for a /32. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From Michael.Dillon at btradianz.com Fri Apr 21 06:48:07 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 21 Apr 2006 11:48:07 +0100 Subject: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: Message-ID: > > If you are interested in understanding this then start here > > http://nys-stlc.syr.edu/lawlibrary/antitrust/antitrustbasics.aspx > > This includes important gold nuggets such as ".. whether the practice > complained of _unreasonably_ restrains competition", "The true test > of legality is whether the restraint imposed is such as _merely > regulates_ and perhaps thereby promotes competition ..." Yes, of course. All laws are like that, especially in a country like the USA which relies heavily on common-law and case-law precedents. People who live and work in the ARIN region tend to develop a gut feel for what is legal and what is not based on their experience in business and exposure to local media. I don't think it is productive to try and second guess on this list, what an American judge might decide. > No, the discussion has been recently brought up at least on those > lists, and it would seem unwise to repeat it on every list. Even if > each region made its own policies, it might be much easier for > everyone (IMHO) if the discussion was held on a common list, and then > when the time comes, folks would each go to their own individual RIR > to make their informed or uninformed decisions. On that, I disagree with you. That kind of centralised system defeats the bottom up nature of the existing RIRs. > Based on observations in v4 land, there are sites that specifically > want to do something other than the first option, and I specifically > want to preclude them from doing so. It is probably not too late to suggest that the ARIN AC include the same "no deaggregation" language as was used for IPv6 LIRs. This was discussed tangentially at the meeting and I don't recall any of the speakers objecting to that. On the other hand, ARIN policy cannot restrict what two peers do between themselves. At this point in time, the global routing table is merely a convenient phrase used in routing discussions. There really is no such thing. Nobody manages the global routing table. There are no explicit agreements on what can or cannot be announced into the global routing table. And so on. If that were to change then your issues would be perfectly within scope. However, this would require the ARIN Board of Trustees to agree to undertake this activity. Interestingly enough, this does seem to be within ARIN's scope if you read items 2, 3, 4 and 6 of the purposes in the ARIN Articles of Incorporation. Assuming that there was to be an RIR function which produced guidelines for management of the global routing table, how would it operate and how would it ensure industry-wide consensus on those rules? --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 21 06:56:52 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 21 Apr 2006 11:56:52 +0100 Subject: [ppml] Proposed Policy: RSA Modification Procedure In-Reply-To: <4447CC22.2060508@arin.net> Message-ID: > Policy Proposal Name: RSA Modification Procedure I know this abbreviation has been in use for a while however, now that the terminology is to be enshrined in policy, I would like to ask the author to change it to RS Agreement. The abreviation RSA is already used for private key cryptology, and as many learned at the last meeting, cryptographic protection of the routing system will be under discussion by ARIN for the next few years. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 21 07:00:25 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 21 Apr 2006 12:00:25 +0100 Subject: [ppml] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <6.2.0.14.2.20060421054902.02df2880@kahuna.telstra.net> Message-ID: > And just to be clear - the problem with the routing economy is that there > is no routing economy. Not surprising since there is no global routing table either. It's all just abstractions in the minds of routing economists. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 21 07:08:07 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 21 Apr 2006 12:08:07 +0100 Subject: [ppml] IPv6 PI space for addressing In-Reply-To: <10793F3BC5C33C489C69893C14242C0904C6F27D@JUPITER> Message-ID: > I've been watching the debate over IPv6 PI space for well over a year > (mostly on NANOG), and one thing stands out to me. Many moons ago, if an > organization intended to run IPv4 in their network, they could secure an > IPv4 allocation even if they did not intend to route that prefix over the > Internet. They still can. > I believe address depletion is still a valid concern with IPv6, and the > draft policies do address this concern. However, I believe the restrictions > on IPv6 PI space should recognize the need for such space outside of the > Internet routing table. Once an LIR has a /32, nobody says that they have to route all of it. They may announce all of it for convenience, but they are free to blackhole all incoming traffic if they want. --Michael Dillon From sleibrand at internap.com Fri Apr 21 08:14:46 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 21 Apr 2006 08:14:46 -0400 (EDT) Subject: [ppml] Proposed Policy: RSA Modification Procedure In-Reply-To: References: Message-ID: On 04/21/06 at 11:56am +0100, Michael.Dillon at btradianz.com wrote: > > Policy Proposal Name: RSA Modification Procedure > > I know this abbreviation has been in use for a while > however, now that the terminology is to be enshrined in > policy, I would like to ask the author to change it > to RS Agreement. I'll second that. We have enough acronym confusion already. :) -Scott > The abreviation RSA is already used > for private key cryptology, and as many learned at the > last meeting, cryptographic protection of the routing > system will be under discussion by ARIN for the next > few years. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From ppml at rs.seastrom.com Fri Apr 21 08:25:40 2006 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Fri, 21 Apr 2006 08:25:40 -0400 Subject: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <0b4301c6652d$15b1def0$3712fea9@ssprunk> (Stephen Sprunk's message of "Fri, 21 Apr 2006 05:19:31 -0500") References: <054601c66496$60f6b210$3712fea9@ssprunk> <20060421032349.GA20024@srv01.cluenet.de> <0b4301c6652d$15b1def0$3712fea9@ssprunk> Message-ID: <87hd4ndsjf.fsf@valhalla.seastrom.com> "Stephen Sprunk" writes: > ARIN has replied to me privately that two IPv6 tunnels over the same > physical link count as "multihoming"; another PPML poster has told me > privately he's actually gotten an ASN that way. > > IMHO this needs to be corrected, but it doesn't appear to be abused except > out of novelty, so it's not a dire emergency. Now, this is an interesting one. Where would you draw the line for diversity of connections being truly "multihomed"? Here are a few scenarios for your consideration: Commodity MPLS from a third party provider (yes, i know this doesn't exist yet) with one pipe going to two ISPs. Commodity Frame Relay or ATM with two DAFs entering the facility, but an inspection of the DLRs for the PVCs shows that they both traverse the same switch. Two SONET connections that are groomed onto the same OC48. Two SONET connections that are physically distinct but enter the customer facility via the same conduit. I'm not so sure that I agree with your implication that justifying an ASN on the basis of two tunnels is "abuse". It might be "poor engineering", "unwise", or "certainly something I would never do", but ARIN policy is intended to apply good stewardship principles, not coerce people's business or engineering plans. We agree that the current level of unconventional registration is likely low. I don't agree that there's anything to "fix" here. By the way, the other way you can justify an ASN is to have a "unique routing policy". What that constitutes is left as an exercise to the reader, but I'm sure that a session in the bar in St. Louis could come up with some really freaky scenarios. Current policy is OK by me. It will be even more OK after 32-bit ASNs are the norm. ---Rob From narten at us.ibm.com Fri Apr 21 08:56:03 2006 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 21 Apr 2006 08:56:03 -0400 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: Message from "Stephen Sprunk" of "Thu, 20 Apr 2006 21:39:44 CDT." <088201c664ec$d991ac60$3712fea9@ssprunk> Message-ID: <200604211256.k3LCu3V5011765@cichlid.raleigh.ibm.com> "Stephen Sprunk" writes: > OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two > pipes or tunnels), and there's not all that many companies doing it. It's > not growing much either. The doors are already wide open for a land rush > and nobody is taking ARIN up on it. Why does everyone assume it'll happen > with v6 if it's not happening with v4, which _is_ useful today? Because today, people are a lot more network savvy, and they now understand the potential value of getting real PI space. Moreover, anyone who understands history, realizes that getting PI space may become harder in the future, rather than easier. Consequently, it would be a smart business move to get PI space ASAP, in case the rules change down the road. i.e, a rather prudent investment. Thomas From narten at us.ibm.com Fri Apr 21 09:06:25 2006 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 21 Apr 2006 09:06:25 -0400 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: Message from Randy Bush of "Fri, 21 Apr 2006 09:27:24 +0300." <17480.31564.910183.899582@roam.psg.com> Message-ID: <200604211306.k3LD6PBO011907@cichlid.raleigh.ibm.com> Let me give a try. Randy Bush writes: > could folk please explain how these various suggestions differ from > 1918 on the dimensions which seem operationally annoying today? e.g. > o leakage of packets with source of unreachable addresses No real difference? But having such unreachable space be globally unique at least allows one to identify the source (if a centrally assigned ULA) and prevents confusion/collision with addresses used by different organizations. > o dns entries with unreachables on the rhs Not sure I understand. but with CULAs (centrally assigned), there is clear owner of the address, and reverse entries can be placed in the DNS. At the meeting, this was said to be useful for utilities like traceroute, that convert the addresses to DNS names for display. > o traceroutes through infrastructure Better to have globally unique addresses than ambiguous addresses? > o dns dynupd for unreachables Not sure what the question is here. > we have a plenty of history that "should not" in an rfc does not > help much. > is there something we can do to not continue the pain while getting > some benefit? Indeed! Thomas From George.Kuzmowycz at aipso.com Fri Apr 21 09:43:57 2006 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Fri, 21 Apr 2006 09:43:57 -0400 Subject: [ppml] IPv6 PI space for addressing Message-ID: "Tony Hain" wrote on 04/20/2006 7:05:22 PM: > brian.knight at us.mizuho-sc.com wrote: [snip] >> I have to say that it seems ARIN and the other RIRs are getting co-opted >> into policing the routing table on behalf of ISP's. And maybe that's the >> best way to do it if any other solution would result in massively ugly >> peering battles. [snip] > Your needs are as valid as any other, and what the policy process needs > is > more input from the enterprise network managers like yourself. Tell > every > company you deal with that now is the time to weigh in and make sure > they > are not locked out by policies that favor the ISP at the expense of > their > customers. > > Tony While I agree that the policy process does appear to need more input from the "enterprise" side, it is difficult to reconcile that with the prevailing sentiment in the existing forums for that process. In the last week on this list alone, I've read essentially the following: - "We can't let you get PI space because you're too dumb to use it correctly" (Can anyone actually provide data to back that up? Looks like >85% of ASes are non-transit -- what percentage of "problems" do they contribute?) - "Go ahead and get your PI space; when we decide not to route it, we'll have the last laugh" (Doesn't sound like a good business model for ISP's, but then what do I know?) - "Go ahead and get your PI space; we'll just submit a policy proposal to take it away every year until we wear you down." (Businesses like contractual certainties. Certainly legislative and regulatory environments in every industry are subject to change and need to be monitored, but having to fight a rear-guard battle year after year just to maintain the status quo is not a very good use of people's time.) From memsvcs at arin.net Fri Apr 21 09:53:40 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 21 Apr 2006 09:53:40 -0400 Subject: [ppml] Policy Proposal 2006-6: Bulk WHOIS agreement expiration clarification Message-ID: <4448E3E4.4070009@arin.net> On April 20, 2006, the ARIN Advisory Council (AC) concluded its review of 'Bulk WHOIS agreement expiration clarification' and accepted it as a formal policy proposal for discussion by the community. The AC is also forwarding the matter to the ARIN Board of Trustees for its consideration. The proposal is designated Policy Proposal 2006-6: Bulk WHOIS agreement expiration clarification. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2006_6.html All persons in the community are encouraged to discuss Policy Proposal 2006-6 in the weeks leading to the ARIN Public Policy Meeting in St. Louis scheduled for October 11-12, 2006. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: Bulk WHOIS agreement expiration clarification Author: Bill Woodcock Proposal Version: 1.0 Proposal type: Modify Policy term: Permanent Policy statement: Text added to the end of "3.1. Bulk Copies of ARIN's WHOIS": If no term of validity or expiration date is included in the policy or AUP, it shall be deemed valid upon acceptance by ARIN and shall conclude after thirty days notice by ARIN, immediately upon cancellation by the other signatory, or immediately upon a violation of its terms. If an expiration date is included, ARIN shall provide thirty days notice prior to the expiration of an AUP agreement, in order that the data recipient shall have the opportunity to receive uninterrupted service. Rationale: Presently, there is no expiration date specified in either the AUP agreement nor in the policy. ARIN whois data recipients receive an FTP login to an ARIN server, which unexpectedly stops working one day, breaking lots of scripts, causing gaps in datasets, and causing people to waste a lot of time debugging, only to find that the login has been deactivated with no forewarning. If ARIN staff are going to arbitrarily decide to "expire" an agreement which has no defined expiration, doing so unilaterally and without notice is an extraordinarily bad idea. Let me just say that I think it's really pitiful that we should need to use the policy process to micromanage operations at this level. But believe me, I wouldn't be wasting my time writing something this trivial if it weren't necessary to solve an actual problem. Timetable for implementation: Immediate. From Michael.Dillon at btradianz.com Fri Apr 21 09:55:39 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 21 Apr 2006 14:55:39 +0100 Subject: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <87hd4ndsjf.fsf@valhalla.seastrom.com> Message-ID: > Commodity Frame Relay or ATM with two DAFs entering the facility, but > an inspection of the DLRs for the PVCs shows that they both traverse > the same switch. > > Two SONET connections that are groomed onto the same OC48. We know that separacy of circuits is subject to change due to the widespread use of switches (DACS, ATM, Ethernet) and the widespread telecom practice of grooming customer circuits over time. It is hard work to ensure that true separacy exists when it is needed to meet customer contract conditions. Given this, I think it would be unwise to specify the degree of separacy in an ARIN policy. It would be almost impossible to enforce such a provision even if you restrict it to new applications. And even then, anyone can comply to get their ASN and PI block, then go back to the pair of IPv6 tunnels for the long haul. ARIN policy has always had to strike a balance. We are not lawmakers or law enforcers. --Michael Dillon From tme at multicasttech.com Fri Apr 21 09:55:47 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 21 Apr 2006 09:55:47 -0400 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <200604211256.k3LCu3V5011765@cichlid.raleigh.ibm.com> References: <200604211256.k3LCu3V5011765@cichlid.raleigh.ibm.com> Message-ID: Hello; On Apr 21, 2006, at 8:56 AM, Thomas Narten wrote: > "Stephen Sprunk" writes: > >> OTOH, it's ridiculously easy to get PIv4 space today (512 hosts >> and two >> pipes or tunnels), and there's not all that many companies doing >> it. It's >> not growing much either. The doors are already wide open for a >> land rush >> and nobody is taking ARIN up on it. Why does everyone assume >> it'll happen >> with v6 if it's not happening with v4, which _is_ useful today? > > Because today, people are a lot more network savvy, and they now > understand the potential value of getting real PI space. Moreover, > anyone who understands history, realizes that getting PI space may > become harder in the future, rather than easier. Consequently, it > would be a smart business move to get PI space ASAP, in case the rules > change down the road. i.e, a rather prudent investment. > No doubt. That still doesn't explain why more people aren't taking advantage of 2002-3 in IPv4. I think that this is an indicator that - there are some small companies that need to multi-home - the numbers of these is fairly small - people are not (yet) viewing PI space as real property. (There are clearly a number of small companies that truly need to multi-home. Streaming and videoconferencing providers, for example, probably should multi-home regardless of their size.) Clearly, I think it would be to everyone's advantage if people (on a wide scale) _never_ start viewing PI space as real property. I think that the best way to ensure that this does not happen is to adopt 2005-1. If there is a near infinite supply of something, there is no need to hoard it. > Thomas > Regards Marshall > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From tme at multicasttech.com Fri Apr 21 10:00:11 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 21 Apr 2006 10:00:11 -0400 Subject: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On Apr 21, 2006, at 9:55 AM, Michael.Dillon at btradianz.com wrote: >> Commodity Frame Relay or ATM with two DAFs entering the >> facility, but >> an inspection of the DLRs for the PVCs shows that they both >> traverse >> the same switch. >> >> Two SONET connections that are groomed onto the same OC48. > > We know that separacy of circuits is subject to change due to > the widespread use of switches (DACS, ATM, Ethernet) and the > widespread telecom practice of grooming customer circuits > over time. It is hard work to ensure that true separacy > exists when it is needed to meet customer contract conditions. Empirically, I would say that it is impossible to be sure. I have heard too many stories of a {fire, collision, back hoe, etc.} taking down two circuits that were supposed to be geographically separated, or circuits that weren't supposed to be going that way at all. If the people charged with doing this can't be sure, how can ARIN ? > Given this, I think it would be unwise to specify the degree > of separacy in an ARIN policy. It would be almost impossible to > enforce such a provision even if you restrict it to new > applications. And even then, anyone can comply to get their > ASN and PI block, then go back to the pair of IPv6 tunnels > for the long haul. > > ARIN policy has always had to strike a balance. We are not > lawmakers or law enforcers. I would agree. Regards Marshall > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From George.Kuzmowycz at aipso.com Fri Apr 21 10:17:18 2006 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Fri, 21 Apr 2006 10:17:18 -0400 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive Message-ID: Marshall Eubanks wrote on 04/21/2006 9:55:47 AM: [snip] > Clearly, I think it would be to everyone's advantage if people (on a > wide scale) _never_ start viewing PI space as real property. At the risk of straying too far OT, why is this "clear"? From greg.stilwell at verizonbusiness.com Fri Apr 21 10:52:36 2006 From: greg.stilwell at verizonbusiness.com (Greg Stilwell) Date: Fri, 21 Apr 2006 10:52:36 -0400 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2:Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> Message-ID: <001a01c66553$3ae73640$d0922799@mcilink.com> Thomas, I would like to see this draft revived, as it seems to be more or less what we were looking for with 2006-2. Stewardship to guarantee uniqueness, and delegation in ip6.arpa. I think the draft will need some revision to make it more palatable, but will reserve my comments for IETF mailing list. Greg -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Thomas Narten Sent: Thursday, April 20, 2006 4:37 PM To: ppml at arin.net Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2:Micro-allocations for Internal Infrastructure - to be revised ] On 4/14/06, Randy Bush wrote: > fwiw, after discussion with jason, i would support a more simple, > direct, and clear proposal to the same end. > > randy Question: I gather that resurrecting http://tools.ietf.org/html?draft=draft-ietf-ipv6-ula-central would also solve the technical problem at hand (since the technical requirement seems to be globally-unique address space, with no need/desire to have it be globally routable). I understand that RFC 4193 style addresses are not "unique enough" for that purpose. Would there be interest in resurrecting the ula-central document? Pros: 1) globally-unique space would be available to everyone, including end sites. I.e., for pretty much any purpose. Even during the ARIN meeting, it was pointed out that anyone with an ASN could/would presumably want something like this. Cons: 1) ARIN pretty vocally shot down the document a year or more ago, and the IETF basically decided "we don't need this so badly as to have a showdown with the ARIN community". Having said that, I (and others) still think the idea has some merit and would be willing to push on it on the IETF end, assuming we wouldn't get a repeat reaction at future meetings for our efforts... Note: AFAIK, no such reaction seemed to come out of APNIC or RIPE. 2) Does solve Jason's problem, but perhaps there is no desire to fight the larger battle at the expense of just solving the narrow/simple problem (i.e., just for ISPs). Note, however, that it will presumably take at least another 6 months (until the St. Louis meeting) to make progress on this. (Realistically, it would probably also take 6 months to get the ula-central document through the IETF, assuming there was no significant opposition from ARIN, so I'm not sure either approach is necessarily longer). 3) Would make such address space available to everyone, including all end sites, not just ISPs. Not sure this is necessarily bad, but it will result in orders of magnitude more such addresses in use. And the concerns raised in the past centered around the fear that ISPs would be asked/forced to route them... I know that there is at least one person willing to resurrect the ula-central document, but I (personally) don't want to invest cycles in it if it's going to get a frosty reception in ARIN again. Been there, done that. Thomas _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From tme at multicasttech.com Fri Apr 21 10:57:29 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 21 Apr 2006 10:57:29 -0400 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: Hello; On Apr 21, 2006, at 10:17 AM, George Kuzmowycz wrote: > > Marshall Eubanks wrote on 04/21/2006 9:55:47 > AM: > > [snip] > >> Clearly, I think it would be to everyone's advantage if people (on a > >> wide scale) _never_ start viewing PI space as real property. > > At the risk of straying too far OT, why is this "clear"? Well, this is just my opinion, but I think that if IP address blocks become real property, you will see hoarding and speculation. I have said before that I regard a spot market in IPv4 address blocks as almost inevitable. In some ways, that might not be too bad (for example, how many people would find that they could give up a few /20's if they could get, say, $ 20,000 for them, at "only" $5 per address!) Markets are an appropriate way to deal with allocation of a finite resource that people use to make money, and hoarding and speculation are just part of the necessary friction that comes along with a market. But, these are "only" numbers, and IPv6 has a lot of them. So there is no reason for a speculative market to develop in IPv6 address blocks, and, if one does, I would regard whatever policies lead to it as a major strategic mistake. Regards Marshall > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From brian.knight at us.mizuho-sc.com Fri Apr 21 11:17:23 2006 From: brian.knight at us.mizuho-sc.com (brian.knight at us.mizuho-sc.com) Date: Fri, 21 Apr 2006 10:17:23 -0500 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 200 6-2: Micro-allocations for Internal Infrastructure - to be revised ] Message-ID: <10793F3BC5C33C489C69893C14242C0904C6F283@JUPITER> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Thomas Narten > Sent: Thursday, April 20, 2006 3:37 PM > To: ppml at arin.net > Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal > 2006-2: Micro-allocations for Internal Infrastructure - to be > revised ] > > > On 4/14/06, Randy Bush wrote: > > > fwiw, after discussion with jason, i would support a more > simple, direct, > > and clear proposal to the same end. > > > > randy > > Question: > > I gather that resurrecting > > http://tools.ietf.org/html?draft=draft-ietf-ipv6-ula-central > > would also solve the technical problem at hand (since the technical > requirement seems to be globally-unique address space, with no > need/desire to have it be globally routable). > > I understand that RFC 4193 style addresses are not "unique enough" for > that purpose. > > Would there be interest in resurrecting the ula-central document? (Gah. Serves me right for not looking back at the list while finishing my mail.) I know this was brought up to solve a different problem, but... ula-central would be a very good thing for us. It directly addresses the problem I laid out in my email. RFC 4193 provides a very, very high probability of a unique identifier. I'm thinking, though, that we and our partners would benefit greatly from the assurance that our identifier is absolutely unique. I feel there would be a strong comfort factor in being able to WHOIS a private range and verify ownership. I could easily see financial exchanges requiring that for membership. Moreover, I especially like the ability to leverage global DNS to resolve unique local addresses. It solves the problem of multiple split-horizon schemes. Under RFC 4193, I would need to set up a split-horizon DNS scheme. Under ula-central I could probably get away with a single global scheme. The requirements to obtain an allocation are perfectly reasonable. I also like that it maintains RFC 4193-style addressing for the operators which may not need centrally-administered addressing. About the only concern I envision would be that enterprises may attempt to apply a single allocation throughout the enterprise. With the M&A game so widely played, that single-allocation model would break down as organizations are grafted and pruned. And, of course, there's simply no need to have a single range. I think it should be part of best practices to have the responsible IT folks from each location obtain (or generate) their own allocations, rather than use a larger allocation provided by the head office or somesuch. -Brian Knight Sr. Network Engineer Mizuho Securities USA http://www.mizuho-sc.com/ * Please note that I do not speak for my employer - only for myself. From william at elan.net Fri Apr 21 11:28:22 2006 From: william at elan.net (william(at)elan.net) Date: Fri, 21 Apr 2006 08:28:22 -0700 (PDT) Subject: [ppml] IPv6 PI for all organisations who already have IPv4 PI (Was: Resurrecting ULA Central ...) In-Reply-To: <1145611324.15716.12.camel@firenze.zurich.ibm.com> References: <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> <20060420210439.GE16281@shell01.corp.tellme.com> <1145611324.15716.12.camel@firenze.zurich.ibm.com> Message-ID: On Fri, 21 Apr 2006, Jeroen Massar wrote: > On Thu, 2006-04-20 at 14:20 -0700, william(at)elan.net wrote: > [..] >> We could probably try it as a global experiment with existing ipv6 >> with setup like: >> 8 bits - IPv6 ASN experiment global prefix >> 32 bits - ASN number >> 24 bits - local network address if possible last 24 bits of ipv4 > > There is something which already exists for all of this: 6to4: > See RFC3056, http://www.ietf.org/rfc/rfc3056.txt > > This will give you, based on your IPv4 address space that you have a > very nice IPv6 /48 per IPv4 /32 that you already have. > > Thus if you have say 192.0.2.1/24 (IPv4 TestNet ;) then you > automatically have: > 192 => 0xc0 0 => 0x00 2 => 0x02 1 => 0x01 > > Thus: 2002:c000:0201::/48 > > But it is a /24, thus it is much bigger (32-24 = 8): > > Making: 2002:c000:0201::/40 Yes, I know about 6to4. What I wrote above is different - there ASN is what gives you unique network and use of IPv4 address in local-network address part is an option to allow companies to switch over faster to ipv6 without rearchitecting their network (and possibly even with some automated device that will do ipv6<->ipv4 translation in this way). This BTW can be done with current IPv6 proposals as well as long as most companies get /48 which is what current proposals all guarantee. > Which you are officially allowed to use when you 'own' the IPv4 /24. There seems to be issues with multiple announcements of 6to4 space, so I can not really announce that /40 or /48 directly. -- William Leibzon Elan Networks william at elan.net From brian.knight at us.mizuho-sc.com Fri Apr 21 12:37:10 2006 From: brian.knight at us.mizuho-sc.com (brian.knight at us.mizuho-sc.com) Date: Fri, 21 Apr 2006 11:37:10 -0500 Subject: [ppml] IPv6 PI space for addressing Message-ID: <10793F3BC5C33C489C69893C14242C0904C6F288@JUPITER> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Michael.Dillon at btradianz.com > Sent: Friday, April 21, 2006 6:08 AM > To: ppml at arin.net > Subject: Re: [ppml] IPv6 PI space for addressing > > > > I've been watching the debate over IPv6 PI space for well > over a year > > (mostly on NANOG), and one thing stands out to me. Many > moons ago, if > an > > organization intended to run IPv4 in their network, they > could secure an > > IPv4 allocation even if they did not intend to route that > prefix over > the > > Internet. > > They still can. True enough. I should have said that the organization could *easily* secure an IPv4 allocation once upon a time. As I said previously, our network is not large enough to justify a /20, whereas 15 years ago I'm reasonably sure the company could've gotten at least a class C allocation. > > I believe address depletion is still a valid concern with > IPv6, and the > > draft policies do address this concern. However, I believe the > restrictions > > on IPv6 PI space should recognize the need for such space > outside of the > > Internet routing table. > > Once an LIR has a /32, nobody says that they have to route all > of it. They may announce all of it for convenience, but they > are free to blackhole all incoming traffic if they want. Having gone to the trouble of justifying its use, an LIR is likely to announce all or some part of that network, now or in the near future. What I'm asking for is a prefix that will never, ever be publicly routed. That's what I meant by "outside of the Internet routing table." -Brian Knight Sr. Network Engineer Mizuho Securities USA http://www.mizuho-sc.com/ * Please note that I do not speak for my employer - only for myself. From mpetach at netflight.com Fri Apr 21 12:42:12 2006 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 21 Apr 2006 09:42:12 -0700 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised In-Reply-To: <1c16a4870604201610i11befa50s91da3e1e8ece72ad@mail.gmail.com> References: <443FFFC6.1060208@arin.net> <17472.692.685697.785280@roam.psg.com> <1c16a4870604201610i11befa50s91da3e1e8ece72ad@mail.gmail.com> Message-ID: <63ac96a50604210942n6b97cc65k426a47f562f095cb@mail.gmail.com> On 4/20/06, Stacy Taylor wrote: > > Hi Everyone! > Would the omission of the 6.10.1 and 6.10.2, sections, (largely > editorial sections to begin with), from this policy proposal be > classified as clarification, or a step in that direction? > 6.10.3 seems to me to be clear on its own. > Thanks! > /Stacy The challenge with simply omitting 6.10.2 is that 6.10.3 specifies the micro-allocation MUST NOT be routed on the global internet. That language is too restrictive to cover the case of microallocations for core DNS servers, which are most useful when they are indeed routed on the global internet, and not filtered. Matt On 4/14/06, Randy Bush wrote: > > fwiw, after discussion with jason, i would support a more simple, > direct, > > and clear proposal to the same end. > > > > randy > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weiler at tislabs.com Fri Apr 21 12:45:25 2006 From: weiler at tislabs.com (Sam Weiler) Date: Fri, 21 Apr 2006 12:45:25 -0400 (EDT) Subject: [ppml] Collapsing Residential and Business Privacy Message-ID: I'm a fan of doing something like this. That said, it may not be trivial to reach consensus on it, and I don't want to see it hold up any incremental changes we can make in the meantime. The immediately available example of such an incremental change is 2006-1. 2006-1 doesn't attempt to move the bit boundary nor cover non-residential customers nor apply any new accountability requirements. Instead it makes a tiny incremental improvment in what we have now. I hope we don't drop it in favor of something more comprehensive. On to the substance... > - eliminate differentiation between residential and business Fine. > - designate /29's and smaller as private Fine. > - reduction of NA postal codes to 3 characters Not so fine. I haven't seen any analysis non-US postal codes suggestion this is reasonable. I'm not even convonced it's reasonable in the US. I'd prefer to see an argument for why we still need partial postal codes -- what use do they serve? > - creating a confidential/undercover registration clause ... No. Unless they get a statutory exemption, LEAs can operate under the same rules as everyone else -- let's not complicate our policy to accomodate them. -- Sam From hannigan at renesys.com Fri Apr 21 13:13:35 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Fri, 21 Apr 2006 13:13:35 -0400 Subject: [ppml] Collapsing Residential and Business Privacy In-Reply-To: References: Message-ID: <7.0.1.0.2.20060421124843.0221b4c0@renesys.com> At 12:45 PM 4/21/2006, Sam Weiler wrote: > > - reduction of NA postal codes to 3 characters > >Not so fine. I haven't seen any analysis non-US postal codes >suggestion this is reasonable. I'm not even convonced it's reasonable >in the US. I'd prefer to see an argument for why we still need >partial postal codes -- what use do they serve? As I explained at the meeting, whois data, particularly city, state, zip+5 is used as an input to triangulate an address for geo-location applications. It is one of multiple inputs. Geo location takes multiple inputs and tries to get them all to agree, much like ntp, and then adjusts based on the responses of the inputs. Losing all location data in whois @ /29 does not really kill geo-locators, but it definately is valuable in the process. There are far more codes than just USPS or Canada Post to consider. I should have gone and looked at this sooner. I'm surprised by some of the areas listed here. I think before anything is done to the postal code, business or residential, there's going to need to be quite a bit of research in order to reach a fair balance. The balance I'm talking about is the use of the postal code in geo-location, eCommerce credit card fraud prevention, and other applications vs. increasing residential privacy. ANGUILLA ANTARCTICA ANTIGUA BAHAMAS BARBADOS BERMUDA BOUVET ISLAND CANADA CAYMAN ISLANDS DOMINICA GRENADA GUADELOUPE HEARD AND MC DONALD ISLANDS JAMAICA MARTINIQUE PUERTO RICO SAINT KITTS AND NEVIS SAINT LUCIA SAINT VINCENT AND THE GRENADINES ST. HELENA ST. PIERRE AND MIQUELON TURKS AND CAICOS ISLANDS UNITED STATES UNITED STATES MINOR OUTLYING ISLANDS VIRGIN ISLANDS (BRITISH) VIRGIN ISLANDS (U.S.) Source: http://www.arin.net/community/ARINcountries.html Can you adjust your presentation on 5 digit (in)security to do an apples for apples 3 vs. 5 and post it somewhere? > > - creating a confidential/undercover registration clause ... > >No. Unless they get a statutory exemption, LEAs can operate under the >same rules as everyone else -- let's not complicate our policy to >accomodate them. This isn't giving the LEA's anything that they don't already have, this is resolving something that a provider of services to USGC organizations brought up. I'm not 100% sure what David is trying to get at since I heard HIPAA compliance thrown into the mix, but it's probably his turn to defend if this solves his problem or not. I'm trying to be "helpful" since I have a large amount of LEA experience in Title III and CALEA and I'm familiar with the process and regulations surrounding lawful orders as a result. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From marla_azinger at eli.net Fri Apr 21 13:15:25 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 21 Apr 2006 10:15:25 -0700 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A52F@wava00s2ke2k01.corp.pvt> I can support the need for some Residential changes. But not commercial and not this way. I can not nor will not support the "collapse" and inclusion of Business/Commercial into this policy. If you work as a hostmaster or ipadmin as I do you will have the unpleasant experience of how even a /29 can be used for spam or other abuse issues. If its being used for commercial purposes then it should be visible who is using it. As for the residential person that is running a office out of the house. Cant we just make it simple and allow this type of scenerio to publish a PO Box address instead of their home address? Moving the size from /30 to /29 is irresponsible and moves us a little further from fighting abuse in a proactive manner and closer to reactive manner. This is not how I choose to work daily. I do everything possible to fight abuse issues proactively. So no, I do not support the following suggested policy changes: - eliminate differentiation between residential and business - designate /29's and smaller as private - reduction of NA postal codes to 3 characters - creating a confidential/undercover registration clause to allow LEA to mask registrations for investigative, intelligence, or other purposes as long as they identify these to ARIN staff AND ARIN is able to handle such information per FISA, Title III. CALEA, and other applicable regulations (IANAL). This follows a concept invoked by DMV's related to license plates. (and a memory jogging by Heather Skanks - thank you!) Thank you Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Martin Hannigan Sent: Tuesday, April 18, 2006 11:19 PM To: ppml at arin.net Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois At 12:25 PM 4/10/2006, Divins, David wrote: >Due to popular demand....Attempt number 3 at an accurate Subject :-) During the XVII meeting, I talked to the author of the residential privacy policy, David Divens, and Aaron Hughes, regarding their concerns over residential and business privacy. My suggestion to the AC (and proposers) regarding proposals would be a rewrite to accomplish the following: - eliminate differentiation between residential and business - designate /29's and smaller as private - reduction of NA postal codes to 3 characters - creating a confidential/undercover registration clause to allow LEA to mask registrations for investigative, intelligence, or other purposes as long as they identify these to ARIN staff AND ARIN is able to handle such information per FISA, Title III. CALEA, and other applicable regulations (IANAL). This follows a concept invoked by DMV's related to license plates. (and a memory jogging by Heather Skanks - thank you!) My recommendation is based on the following prefix distribution data that we have compiled based on whois data not older than 2 weeks. It shows that /29 is over 60% of all data and we would improve overall privacy by X factors. I think it is fair to say that the vast majority of residences are within /29, and I agree with Owen Delong that privacy is not an expectation for business whois data. This is more balanced than a complete masking of location data. I would like to hear what LEA's think of this, and I would be happy to consider adjustments on the confidential registration idea. Current applications of whois data include geo-location, which does not necessarily rely solely on whois data, but does use it for triangulation purposes. I think we would be surprised at the list of applications utilizing the postal code for this, and I am informing other geo-locators of this proposal and location of discussion so that they may participate if desired. MASK PFX 4 2 6 1 7 2 8 188 9 1 10 6 11 13 12 36 13 81 14 216 15 411 16 7287 17 681 18 1399 19 3170 20 6004 21 4794 22 10262 23 19743 24 120053 25 33036 26 38778 27 103976 28 137726 29 847640 (66% of all registrations) 30 184 31 3 Non-CIDR=11078 -- 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 woody at pch.net Fri Apr 21 13:37:35 2006 From: woody at pch.net (Bill Woodcock) Date: Fri, 21 Apr 2006 10:37:35 -0700 (PDT) Subject: [ppml] Policy Proposal 2006-6: Bulk WHOIS agreement expiration clarification In-Reply-To: <4448E3E4.4070009@arin.net> References: <4448E3E4.4070009@arin.net> Message-ID: > All persons in the community are encouraged to discuss Policy Proposal > 2006-6 in the weeks leading to the ARIN Public Policy Meeting in St. > Louis scheduled for October 11-12, 2006. FYI, I've gotten a lot of really good feedback on this already, and plan to make a significant revision in the next couple of weeks. -Bill From owen at delong.com Fri Apr 21 13:49:30 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Apr 2006 10:49:30 -0700 Subject: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <0b4301c6652d$15b1def0$3712fea9@ssprunk> References: <054601c66496$60f6b210$3712fea9@ssprunk> <20060421032349.GA20024@srv01.cluenet.de> <0b4301c6652d$15b1def0$3712fea9@ssprunk> Message-ID: <418ABC4E7F319E31AF9A7871@imac-en0.delong.sj.ca.us> > As far as fees, if the org already has IPv4 space of some sort, the PIv6 > assignment will presumably be free through 31 Dec 07 like PAv6 > assignments and USD1250/yr after that. The idea of charging thousands > of dollars more to discourage PIv6 applications is not in line with > existing fee schedules and rather pointless since folks can apparently > claim to be LIRs without much difficulty and pay USD2250/yr for a /32. > Only if the ORG is an ARIN member. If they are not a member, there is no waiver. Membership is $500/year if you are not an ISP subscriber member (which involves paying significantly more for your allocation/assignment unless you are a v6-only ISP). Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Fri Apr 21 13:55:35 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Apr 2006 10:55:35 -0700 Subject: [ppml] Proposed Policy: RSA Modification Procedure In-Reply-To: References: Message-ID: --On April 21, 2006 11:56:52 AM +0100 Michael.Dillon at btradianz.com wrote: >> Policy Proposal Name: RSA Modification Procedure > > I know this abbreviation has been in use for a while > however, now that the terminology is to be enshrined in > policy, I would like to ask the author to change it > to RS Agreement. The abreviation RSA is already used > for private key cryptology, and as many learned at the > last meeting, cryptographic protection of the routing > system will be under discussion by ARIN for the next > few years. > Since no policy refers to any brand name and RSA is simply a brand name for public key cryptOGRAPHy, I don't see any real need to worry about confusion here. Almost any TLA has multiple meanings. Heck, I find myself having to work really hard at NRPM (Number Resource Policy Manual) because my brain keeps going to NPRM (Notice of Proposed Rule Making), but, we've managed to muddle through that. I think context will make clear which meaning of RSA we are discussing. However, if there appears to be wider concern about this issue, I will replace the language in the proposal. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From George.Kuzmowycz at aipso.com Fri Apr 21 14:00:57 2006 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Fri, 21 Apr 2006 14:00:57 -0400 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive Message-ID: Marshall Eubanks 04/21/2006 wrote on 10:57:29 AM: > Hello; > > On Apr 21, 2006, at 10:17 AM, George Kuzmowycz wrote: > >> >> Marshall Eubanks wrote on 04/21/2006 9:55:47 >> AM: >> >> [snip] >> >>> Clearly, I think it would be to everyone's advantage if people (on a >> >>> wide scale) _never_ start viewing PI space as real property. >> >> At the risk of straying too far OT, why is this "clear"? > > Well, this is just my opinion, but I think that if IP address blocks > become real property, you will see hoarding and speculation. > > I have said before that I regard a spot market in IPv4 address blocks > as almost inevitable. > In some ways, that might not be too bad (for example, how many people > would find that they > could give up a few /20's if they could get, say, $ 20,000 for them, > at "only" $5 per address!) > Markets are an appropriate way to deal with allocation of a finite > resource that people use to make money, > and hoarding and speculation are just part of the necessary friction > that comes along with a market. > > But, these are "only" numbers, and IPv6 has a lot of them. So there > is no reason for > a speculative market to develop in IPv6 address blocks, and, if one > does, I would > regard whatever policies lead to it as a major strategic mistake. If there is a more appropriate place to discuss the underlying economics, please let me know. But I'm still not clear whether the objection is to addresses possibly becoming property, or to the idea of an independent (i.e. not controlled by RIRs nor possibly by ISPs) market in addresses. There is plenty of precedent for the idea of real property being subject to restrictions or even prohibitions on re-sale (covenants on land deeds, etc.), just as there is precedent for a competitive market in common resources which are not property (RF spectrum auctions.) I know analogies are generally bad, but which, if either, is closer to what you want? From sleibrand at internap.com Fri Apr 21 14:40:13 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 21 Apr 2006 14:40:13 -0400 (EDT) Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2:Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <001a01c66553$3ae73640$d0922799@mcilink.com> References: <001a01c66553$3ae73640$d0922799@mcilink.com> Message-ID: On 04/21/06 at 10:52am -0400, Greg Stilwell I think the draft will need some revision to make it more palatable, but > will reserve my comments for IETF mailing list. Which IETF WG is in charge of draft-ietf-ipv6-ula-central? There isn't still an ipv6 WG, is there? -Scott > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Thomas Narten > Sent: Thursday, April 20, 2006 4:37 PM > To: ppml at arin.net > Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal > 2006-2:Micro-allocations for Internal Infrastructure - to be revised ] > > On 4/14/06, Randy Bush wrote: > > > fwiw, after discussion with jason, i would support a more simple, > > direct, and clear proposal to the same end. > > > > randy > > Question: > > I gather that resurrecting > > http://tools.ietf.org/html?draft=draft-ietf-ipv6-ula-central > > would also solve the technical problem at hand (since the technical > requirement seems to be globally-unique address space, with no need/desire > to have it be globally routable). > > I understand that RFC 4193 style addresses are not "unique enough" for that > purpose. > > Would there be interest in resurrecting the ula-central document? > > Pros: > > 1) globally-unique space would be available to everyone, including end > sites. I.e., for pretty much any purpose. Even during the ARIN > meeting, it was pointed out that anyone with an ASN could/would > presumably want something like this. > > Cons: > > 1) ARIN pretty vocally shot down the document a year or more ago, and > the IETF basically decided "we don't need this so badly as to have > a showdown with the ARIN community". Having said that, I (and > others) still think the idea has some merit and would be willing to > push on it on the IETF end, assuming we wouldn't get a repeat > reaction at future meetings for our efforts... > > Note: AFAIK, no such reaction seemed to come out of APNIC or RIPE. > > 2) Does solve Jason's problem, but perhaps there is no desire to fight > the larger battle at the expense of just solving the narrow/simple > problem (i.e., just for ISPs). Note, however, that it will > presumably take at least another 6 months (until the St. Louis > meeting) to make progress on this. (Realistically, it would > probably also take 6 months to get the ula-central document through > the IETF, assuming there was no significant opposition from ARIN, > so I'm not sure either approach is necessarily longer). > > 3) Would make such address space available to everyone, including all > end sites, not just ISPs. Not sure this is necessarily bad, but it > will result in orders of magnitude more such addresses in use. And > the concerns raised in the past centered around the fear that ISPs > would be asked/forced to route them... > > I know that there is at least one person willing to resurrect the > ula-central document, but I (personally) don't want to invest cycles in it > if it's going to get a frosty reception in ARIN again. Been there, done > that. > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From bonomi at mail.r-bonomi.com Fri Apr 21 14:53:22 2006 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 21 Apr 2006 13:53:22 -0500 (CDT) Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois Message-ID: <200604211853.k3LIrMBH001958@s25.firmware.com> > Date: Fri, 21 Apr 2006 10:15:25 -0700 > From: "Azinger, Marla" > To: > Subject: Re: [ppml] Collapsing Residential and Business Privacy (ease of > use) Was: Re: Privacy of Non-Residential Reassignments in > Public Whois > > I can support the need for some Residential changes. But not commercial and > not this way. > > I can not nor will not support the "collapse" and inclusion of Business/ > Commercial into this policy. If you work as a hostmaster or ipadmin as > I do you will have the unpleasant experience of how even a /29 can be used > for spam or other abuse issues. If its being used for commercial purposes > then it should be visible who is using it. > > As for the residential person that is running a office out of the house. > Cant we just make it simple and allow this type of scenerio to publish a > PO Box address instead of their home address? > > Moving the size from /30 to /29 is irresponsible and moves us a little > further from fighting abuse in a proactive manner and closer to reactive > manner. This is not how I choose to work daily. I do everything possible > to fight abuse issues proactively. > > So no, I do not support the following suggested policy changes: > - eliminate differentiation between residential and business > - designate /29's and smaller as private > - reduction of NA postal codes to 3 characters > - creating a confidential/undercover registration clause to allow > LEA to mask registrations for investigative, intelligence, > or other purposes as long as they identify these to ARIN > staff AND ARIN is able to handle such information per FISA, Title III. > CALEA, and other applicable regulations (IANAL). This > follows a concept invoked by DMV's related to license plates. > (and a memory jogging by Heather Skanks - thank you!) > > > Thank you > Marla Azinger > Frontier Communications > Folks, Watching the on-going discussion on this matter, it seems to me that something _very_ fundamental has been overlooked. As in, the 'fundamental purpose' of address-block delegations. Which is to identify the entity that is 'responsible' for activities emmenating from that address-block. In the case of PI space, there' no question as to who that party is, and one of the requirements for getting/keeping PI space is (or *should* be) 'publicly admitting' that you _are_ reponsible for that space. As for PA space .... *IF* the ultimate assignee of that address block is willing to take responsibility for those activities, then they have to be willing to stand up and say "I'm responsibile, and _here_ is how you can contact me". That includes, at a minimum, a working phone number, and a valid snail-mail address. IF =NOT=, then all 'responsibility' lies with the penultimate assignee -- the ISP (or, in rare cases, 'other party') that delegated that sub-block to the end-user -- and the name should be simply something like: {{provider}} Customer {{id no.}} with *all* other information being that of that immediate 'upstream' entity. Note: if one actually uses the '{{'/'}}' (or something similar) around the provider name, it becomes 'trivial' to mechanically parse for whether or not the 'responsible' party is the end-user. Side-bar: a direct corollary of this -- if you, as the end-user, do _not_ claim 'responsibility' for your network, you are authorizing your upstream to do whatever "management" of the datastream out of your network is 'desirable' for the world at large. e.g. if you're spewing spam, or virus- attacks, or something else maloderus, the uptsream can (and should) drop filters in for that odiferous traffic; _then_ notify you to 'clean up your act'. And pull the filters only after you've shown that you've done it. That _is_, after all, only what a 'responsible' end-user would do, upon receipt of notice of such activity originating from said end-user's network. From that viewpoint, the argument about a /30 vs a /29, vs a /19 (or what- ever), is entirely moot -- there is _always_ a clearly-identified 'responsible' party for the address-block. It is entirely up to the individual provider to decide at what size-point, *if*any*, they require the end-user to 'take responsibility' themselves. Some providers could require that every user regardless of size, 'take responsibility' for their 'network'; while others could allow anyone, again 'regardless of size', to remain 'private'. In the grand scheme of things, it -doesn't- make any difference, as long as you have the means to reach the 'responsible' party. It also renders moot the law-enforcement issue -- they can simply "request" to be shown only as a provider 'customer'. *OR*, if they have a fully functioning 'front' operation, they can use the name/address/etc. for that front -- since contact with the 'front' -will- put people in contact with the 'responsible' party. Lastly, in the case of needing to take legal action, you can simply name the provider _and_ "John Doe, a.k.a.{{provider}} Customer {{id no.}}", subpoena the provider record for the identity of that customer, amend the suit to include John Doe' real name and drop the provider. As for 'geo-location' services, address-block 'whois' info is largely meaningless to start with. For starters, IBM's "corporate" address in Deleware (or even 'headquarters' in NY) says nothing about where their network equipment is. And, anybody who is maintaining 'geographically diverse' back-up sytems -- especially on as smaller scale, using PA address-space -- may have networks in 'remote' parts of the country, with the _same_ address-block contact-address info. I'm sorry, but trying to 'preserve accuracy' for geo-location services is a straw-man, at best. *UNLESS* (and this just occurred to me) you're only talking about cross- checking address information on the registration for conistency -- e.g. street-address matches zipcode, zipcode matches phone-number, etc. Sidebar: cross-checking phone numbers (of 'smaller' operations) is getting _very_ problematic. with 'unlimited' long-distance, more and more people are _keeping_ their old cell-phone numbers when they move. On a telephone list I was dealing with recently, I had "Washington D.C. area" phone numbers in area-codes 612, 619, 770, 303, 414, 816, 208, 510, 641, and 419, as well as the usual D.C., Maryland, and Virgina suspects. These were numbers that have been associated with D.C. addresses for at least the past 2-3 years. From alh-ietf at tndh.net Fri Apr 21 14:53:48 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 21 Apr 2006 11:53:48 -0700 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2:Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: Message-ID: <0bc101c66574$ecc87650$d447190a@tndh.net> Scott Leibrand wrote: > > I think the draft will need some revision to make it more palatable, but > > will reserve my comments for IETF mailing list. > > Which IETF WG is in charge of draft-ietf-ipv6-ula-central? There isn't > still an ipv6 WG, is there? Well if the document is not ready a new working group would be formed. If it is basically ready, a few editorial comments would be handled by taking the document straight to IETF last call. Tony From dsd at servervault.com Fri Apr 21 15:07:26 2006 From: dsd at servervault.com (Divins, David) Date: Fri, 21 Apr 2006 15:07:26 -0400 Subject: [ppml] Collapsing Residential and Business Privacy (ease ofuse) Was: Re: Privacy of Non-Residential Reassignments inPublic Whois Message-ID: Thank you! Yes, yes, and Yes. The below post is much more concise than I have been. -dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Robert Bonomi Sent: Friday, April 21, 2006 2:53 PM To: ppml at arin.net Subject: Re: [ppml] Collapsing Residential and Business Privacy (ease ofuse) Was: Re: Privacy of Non-Residential Reassignments inPublic Whois > Date: Fri, 21 Apr 2006 10:15:25 -0700 > From: "Azinger, Marla" > To: > Subject: Re: [ppml] Collapsing Residential and Business Privacy (ease of > use) Was: Re: Privacy of Non-Residential Reassignments in > Public Whois > > I can support the need for some Residential changes. But not > commercial and not this way. > > I can not nor will not support the "collapse" and inclusion of > Business/ Commercial into this policy. If you work as a hostmaster > or ipadmin as I do you will have the unpleasant experience of how even > a /29 can be used for spam or other abuse issues. If its being used > for commercial purposes then it should be visible who is using it. > > As for the residential person that is running a office out of the house. > Cant we just make it simple and allow this type of scenerio to publish > a PO Box address instead of their home address? > > Moving the size from /30 to /29 is irresponsible and moves us a little > further from fighting abuse in a proactive manner and closer to > reactive manner. This is not how I choose to work daily. I do > everything possible to fight abuse issues proactively. > > So no, I do not support the following suggested policy changes: > - eliminate differentiation between residential and business > - designate /29's and smaller as private > - reduction of NA postal codes to 3 characters > - creating a confidential/undercover registration clause to allow > LEA to mask registrations for investigative, intelligence, > or other purposes as long as they identify these to ARIN > staff AND ARIN is able to handle such information per FISA, Title III. > CALEA, and other applicable regulations (IANAL). This > follows a concept invoked by DMV's related to license plates. > (and a memory jogging by Heather Skanks - thank you!) > > > Thank you > Marla Azinger > Frontier Communications > Folks, Watching the on-going discussion on this matter, it seems to me that something _very_ fundamental has been overlooked. As in, the 'fundamental purpose' of address-block delegations. Which is to identify the entity that is 'responsible' for activities emmenating from that address-block. In the case of PI space, there' no question as to who that party is, and one of the requirements for getting/keeping PI space is (or *should* be) 'publicly admitting' that you _are_ reponsible for that space. As for PA space .... *IF* the ultimate assignee of that address block is willing to take responsibility for those activities, then they have to be willing to stand up and say "I'm responsibile, and _here_ is how you can contact me". That includes, at a minimum, a working phone number, and a valid snail-mail address. IF =NOT=, then all 'responsibility' lies with the penultimate assignee -- the ISP (or, in rare cases, 'other party') that delegated that sub-block to the end-user -- and the name should be simply something like: {{provider}} Customer {{id no.}} with *all* other information being that of that immediate 'upstream' entity. Note: if one actually uses the '{{'/'}}' (or something similar) around the provider name, it becomes 'trivial' to mechanically parse for whether or not the 'responsible' party is the end-user. Side-bar: a direct corollary of this -- if you, as the end-user, do _not_ claim 'responsibility' for your network, you are authorizing your upstream to do whatever "management" of the datastream out of your network is 'desirable' for the world at large. e.g. if you're spewing spam, or virus- attacks, or something else maloderus, the uptsream can (and should) drop filters in for that odiferous traffic; _then_ notify you to 'clean up your act'. And pull the filters only after you've shown that you've done it. That _is_, after all, only what a 'responsible' end-user would do, upon receipt of notice of such activity originating from said end-user's network. From that viewpoint, the argument about a /30 vs a /29, vs a /19 (or what- ever), is entirely moot -- there is _always_ a clearly-identified 'responsible' party for the address-block. It is entirely up to the individual provider to decide at what size-point, *if*any*, they require the end-user to 'take responsibility' themselves. Some providers could require that every user regardless of size, 'take responsibility' for their 'network'; while others could allow anyone, again 'regardless of size', to remain 'private'. In the grand scheme of things, it -doesn't- make any difference, as long as you have the means to reach the 'responsible' party. It also renders moot the law-enforcement issue -- they can simply "request" to be shown only as a provider 'customer'. *OR*, if they have a fully functioning 'front' operation, they can use the name/address/etc. for that front -- since contact with the 'front' -will- put people in contact with the 'responsible' party. Lastly, in the case of needing to take legal action, you can simply name the provider _and_ "John Doe, a.k.a.{{provider}} Customer {{id no.}}", subpoena the provider record for the identity of that customer, amend the suit to include John Doe' real name and drop the provider. As for 'geo-location' services, address-block 'whois' info is largely meaningless to start with. For starters, IBM's "corporate" address in Deleware (or even 'headquarters' in NY) says nothing about where their network equipment is. And, anybody who is maintaining 'geographically diverse' back-up sytems -- especially on as smaller scale, using PA address-space -- may have networks in 'remote' parts of the country, with the _same_ address-block contact-address info. I'm sorry, but trying to 'preserve accuracy' for geo-location services is a straw-man, at best. *UNLESS* (and this just occurred to me) you're only talking about cross- checking address information on the registration for conistency -- e.g. street-address matches zipcode, zipcode matches phone-number, etc. Sidebar: cross-checking phone numbers (of 'smaller' operations) is getting _very_ problematic. with 'unlimited' long-distance, more and more people are _keeping_ their old cell-phone numbers when they move. On a telephone list I was dealing with recently, I had "Washington D.C. area" phone numbers in area-codes 612, 619, 770, 303, 414, 816, 208, 510, 641, and 419, as well as the usual D.C., Maryland, and Virgina suspects. These were numbers that have been associated with D.C. addresses for at least the past 2-3 years. _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From memsvcs at arin.net Fri Apr 21 16:18:38 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 21 Apr 2006 16:18:38 -0400 Subject: [ppml] ARIN XVII Meeting Report Now Available Message-ID: <44493E1E.7080708@arin.net> The ARIN community recently concluded the ARIN XVII Public Policy and Members Meetings, held in Montreal, Quebec, April 9-12, 2006. The meeting report includes presentations, webcast archives, summary notes, and transcripts of these meetings, and is now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XVII/ In addition to these files, the page referenced above has links to presentations for the Sunday "Getting Started with IPv6" workshop, tutorials, and Open Policy Hour. We thank all in the community who participated either in person or remotely, and look forward to seeing you all again for ARIN XVIII in St. Louis, Missouri, October 11-13, 2006. Regards, Member Services American Registry for Internet Numbers (ARIN) From jason.schiller at mci.com Fri Apr 21 17:07:59 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Fri, 21 Apr 2006 17:07:59 -0400 (EDT) Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised In-Reply-To: <63ac96a50604210942n6b97cc65k426a47f562f095cb@mail.gmail.com> Message-ID: Matt, Let me try to clarify the question that I think Stacy is trying to put forward (Stacy please correct me if I'm wrong). Sections 6.10.1 and 6.10.2 are an attempt divide up the existing policy into discrete sections in order to clarify things. The goal here was to simply seperate out the text of the existing policy into stuff that applies to all micro-allocations, or stuff that applies only to 1. public exchange points, 2. core DNS servers, or 3. IANA or RIR allocations. Assume for a moment that sections 6.10.1 and 6.10.2 only make editorial changes and do not change the policy. Assume this proposal is replaced with two seperarte proposals. The first proposal simply makes editorial changes (but no policy changes) to organize, clarify, and divide up the text into sections. The second proposal would be as follows: -------- Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations MUST NOT be routed on global Internet. Internal infrastructure allocations MUST be allocated from specific blocks reserved only for this purpose. -------- Assume the text above is contained in such a way as it is clear that this text would only apply to micro-allocations for internal infrastructure. This proposal would not attempt to modify the existing micro-allocation policies. In other words the text about "MUST NOT be routed" would only apply to micro-allocations for internal infrastructure. The questions is would the second proposal as defined above be a move in the right direction? In other words would people support this proposal? The question I would like to ask is if there would be more or less support for the following: 1. complete removal of the "MUST NOT be routed" sentence 2. rewrite of "MUST NOT be routed" to "It is intended that internal infrastructure allocations are not routed on the global Internet." 3. keeping the "MUST NOT be routed" sentence as is 4. Adding text indicating that if the internal infrastructure allocation is routed on the global Internet then ARIN can (or will) reclaim the space. ___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 Fri, 21 Apr 2006, Matthew Petach wrote: > Date: Fri, 21 Apr 2006 09:42:12 -0700 > From: Matthew Petach > To: Stacy Taylor > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2006-2: Micro-allocations for > Internal Infrastructure - to be revised > > On 4/20/06, Stacy Taylor wrote: > > > > Hi Everyone! > > Would the omission of the 6.10.1 and 6.10.2, sections, (largely > > editorial sections to begin with), from this policy proposal be > > classified as clarification, or a step in that direction? > > 6.10.3 seems to me to be clear on its own. > > Thanks! > > /Stacy > > > The challenge with simply omitting 6.10.2 is that 6.10.3 specifies > the micro-allocation MUST NOT be routed on the global internet. > > That language is too restrictive to cover the case of microallocations > for core DNS servers, which are most useful when they are indeed > routed on the global internet, and not filtered. > > Matt > > On 4/14/06, Randy Bush wrote: > > > fwiw, after discussion with jason, i would support a more simple, > > direct, > > > and clear proposal to the same end. > > > > > > randy > > > > > > _______________________________________________ > > > PPML mailing list > > > PPML at arin.net > > > http://lists.arin.net/mailman/listinfo/ppml > > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > From ipgoddess at gmail.com Fri Apr 21 17:23:44 2006 From: ipgoddess at gmail.com (Stacy Taylor) Date: Fri, 21 Apr 2006 14:23:44 -0700 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised In-Reply-To: References: <63ac96a50604210942n6b97cc65k426a47f562f095cb@mail.gmail.com> Message-ID: <1c16a4870604211423r14132fdfv1f6dc224b1d2263f@mail.gmail.com> Thank you, Jason. That is indeed what I was asking. On 4/21/06, Jason Schiller (schiller at uu.net) wrote: > Matt, > > Let me try to clarify the question that I think Stacy is trying to put > forward (Stacy please correct me if I'm wrong). > > Sections 6.10.1 and 6.10.2 are an attempt divide up the existing policy > into discrete sections in order to clarify things. The goal here was to > simply seperate out the text of the existing policy into stuff that > applies to all micro-allocations, or stuff that applies only to > 1. public exchange points, 2. core DNS servers, or 3. IANA or RIR > allocations. > > Assume for a moment that sections 6.10.1 and 6.10.2 only make editorial > changes and do not change the policy. > > Assume this proposal is replaced with two seperarte proposals. The first > proposal simply makes editorial changes (but no policy changes) to > organize, clarify, and divide up the text into sections. > > The second proposal would be as follows: > > -------- > Organizations that currently hold IPv6 allocations may apply for a > micro-allocation for internal infrastructure. Applicant must provide > justification indicating why a separate non-routed block is required. > Justification must include why a sub-allocation of currently held IP space > cannot be utilized. > > Internal infrastructure allocations MUST NOT be routed on global Internet. > > Internal infrastructure allocations MUST be allocated from specific blocks > reserved only for this purpose. > -------- > > Assume the text above is contained in such a way as it is clear that this > text would only apply to micro-allocations for internal infrastructure. > > This proposal would not attempt to modify the existing micro-allocation > policies. In other words the text about "MUST NOT be routed" would only > apply to micro-allocations for internal infrastructure. > > The questions is would the second proposal as defined above be a move in > the right direction? In other words would people support this proposal? > > > The question I would like to ask is if there would be more or less support > for the following: > > 1. complete removal of the "MUST NOT be routed" sentence > > 2. rewrite of "MUST NOT be routed" to "It is intended that internal > infrastructure allocations are not routed on the global Internet." > > 3. keeping the "MUST NOT be routed" sentence as is > > 4. Adding text indicating that if the internal infrastructure allocation > is routed on the global Internet then ARIN can (or will) reclaim the > space. > > ___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 Fri, 21 Apr 2006, Matthew Petach wrote: > > > Date: Fri, 21 Apr 2006 09:42:12 -0700 > > From: Matthew Petach > > To: Stacy Taylor > > Cc: ppml at arin.net > > Subject: Re: [ppml] Policy Proposal 2006-2: Micro-allocations for > > Internal Infrastructure - to be revised > > > > On 4/20/06, Stacy Taylor wrote: > > > > > > Hi Everyone! > > > Would the omission of the 6.10.1 and 6.10.2, sections, (largely > > > editorial sections to begin with), from this policy proposal be > > > classified as clarification, or a step in that direction? > > > 6.10.3 seems to me to be clear on its own. > > > Thanks! > > > /Stacy > > > > > > The challenge with simply omitting 6.10.2 is that 6.10.3 specifies > > the micro-allocation MUST NOT be routed on the global internet. > > > > That language is too restrictive to cover the case of microallocations > > for core DNS servers, which are most useful when they are indeed > > routed on the global internet, and not filtered. > > > > Matt > > > > On 4/14/06, Randy Bush wrote: > > > > fwiw, after discussion with jason, i would support a more simple, > > > direct, > > > > and clear proposal to the same end. > > > > > > > > randy > > > > > > > > _______________________________________________ > > > > PPML mailing list > > > > PPML at arin.net > > > > http://lists.arin.net/mailman/listinfo/ppml > > > > > > > _______________________________________________ > > > PPML mailing list > > > PPML at arin.net > > > http://lists.arin.net/mailman/listinfo/ppml > > > > > > > From hannigan at renesys.com Fri Apr 21 18:35:13 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Fri, 21 Apr 2006 18:35:13 -0400 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: <200604211853.k3LIrMBH001958@s25.firmware.com> References: <200604211853.k3LIrMBH001958@s25.firmware.com> Message-ID: <7.0.1.0.2.20060421173923.022bce78@renesys.com> At 02:53 PM 4/21/2006, Robert Bonomi wrote: > > Date: Fri, 21 Apr 2006 10:15:25 -0700 > > From: "Azinger, Marla" > > To: > > Subject: Re: [ppml] Collapsing Residential and Business Privacy (ease of > > use) Was: Re: Privacy of Non-Residential Reassignments in > > Public Whois > > > > I can support the need for some Residential changes. But not > commercial and > > not this way. > > > > I can not nor will not support the "collapse" and inclusion of Business/ > > Commercial into this policy. If you work as a hostmaster or ipadmin as > > I do you will have the unpleasant experience of how even a /29 can be used > > for spam or other abuse issues. If its being used for commercial purposes > > then it should be visible who is using it. > > > > As for the residential person that is running a office out of the house. > > Cant we just make it simple and allow this type of scenerio to publish a > > PO Box address instead of their home address? > > > > Moving the size from /30 to /29 is irresponsible and moves us a little > > further from fighting abuse in a proactive manner and closer to reactive > > manner. This is not how I choose to work daily. I do everything possible > > to fight abuse issues proactively. > > > > So no, I do not support the following suggested policy changes: > > - eliminate differentiation between residential and business > > - designate /29's and smaller as private > > - reduction of NA postal codes to 3 characters > > - creating a confidential/undercover registration clause to allow > > LEA to mask registrations for investigative, intelligence, > > or other purposes as long as they identify these to ARIN > > staff AND ARIN is able to handle such information per FISA, Title III. > > CALEA, and other applicable regulations (IANAL). This > > follows a concept invoked by DMV's related to license plates. > > (and a memory jogging by Heather Skanks - thank you!) > > > > > > Thank you > > Marla Azinger > > Frontier Communications > > > >Folks, > > Watching the on-going discussion on this matter, it seems to me that >something _very_ fundamental has been overlooked. As in, the 'fundamental >purpose' of address-block delegations. Which is to identify the entity >that is 'responsible' for activities emmenating from that address-block. > > In the case of PI space, there' no question as to who that party is, and >one of the requirements for getting/keeping PI space is (or *should* be) >'publicly admitting' that you _are_ reponsible for that space. > > > As for 'geo-location' services, address-block 'whois' info is largely >meaningless to start with. For starters, IBM's "corporate" address in >Deleware (or even 'headquarters' in NY) says nothing about where their >network equipment is. And, anybody who is maintaining 'geographically >diverse' back-up sytems -- especially on as smaller scale, using PA >address-space -- may have networks in 'remote' parts of the country, >with the _same_ address-block contact-address info. I'm sorry, but trying >to 'preserve accuracy' for geo-location services is a straw-man, at best. >*UNLESS* (and this just occurred to me) you're only talking about cross- >checking address information on the registration for conistency -- e.g. >street-address matches zipcode, zipcode matches phone-number, etc. > Robert, Not entirely a straw man. I think that eliminating /29 data entirely, for example, would not impact my use of geo location at all. In fact, for the application I had in mind, I only need /24 and larger really. There is a larger point related to "other" uses of whois data so I wouldn't get hung up totally on geo location, but consider the bigger picture. I'm focused on it only because that's what interests me at the moment. Marla made a good point about identifying spammers and abuse needs, but in all blocks that could be obfuscated, I think the idea is that the LIR would actually be aware of who was using that block. Having been a hostmaster and ipadmin for too many years that I'd like to not remember, it's a valid point, but addressable. As I have explained in the case of geo-location, the whois data is used as an input, one of many, to attempt to sort of triangulate an address, usually down to City/State/Country. There are some invalidations that take place and are dealt with in the accuracy engines. The whois data does not lose it's value in the case that you describe since it would likely weaken the accuracy "score" and the application would seek out "other" inputs for validation as a result. There are some very interesting things going on out there with many pieces of the database regardless of how meaningless it may be to some. I wonder how many people take bulk whois data? If I can explain anything more about g/l, let me know. Thanks for the information. Sidenote, and feel free to separate this out if you are going to respond: How would the LEA case you describe work for reporting utilization when it was not a store front operation? We still have the case of the status quo. I'm fine with whatever happens there to be honest. I was interested only as related to past experience. If you would call everyone "customer" or "business", why bother collecting any data for public view at all? It seems like we may as well go back to Internet Network Managers handbook styles of presentation. Enough said! If I can explain anything further about geo location, please let me know! Best Regards, -M< From bmanning at vacation.karoshi.com Fri Apr 21 20:28:05 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 22 Apr 2006 00:28:05 +0000 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> References: <63ac96a50604200959t15548f98vfd36c1165189f7f3@mail.gmail.com> <200604202036.k3KKabB0028759@cichlid.raleigh.ibm.com> Message-ID: <20060422002805.GA1593@vacation.karoshi.com.> On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: > Question: > > I gather that resurrecting > > http://tools.ietf.org/html?draft=draft-ietf-ipv6-ula-central > > would also solve the technical problem at hand (since the technical > requirement seems to be globally-unique address space, with no > need/desire to have it be globally routable). please define "globally routable". unless hardwired to reject an address, virtually all addresses are potentially "globally" routable. if there is a potentialy for non-unique assignment, then the possibility of routing said prefix will lead to ambiguity... so fundamentally, most folks seem to want verifiable, unique, persistant address assignments. routablity is a function of the ISP, not the address registry... correct? > > Would there be interest in resurrecting the ula-central document? > > Pros: > > 1) globally-unique space would be available to everyone, including end > sites. I.e., for pretty much any purpose. Even during the ARIN > meeting, it was pointed out that anyone with an ASN could/would > presumably want something like this. > > Cons: > > 1) ARIN pretty vocally shot down the document a year or more ago, and > the IETF basically decided "we don't need this so badly as to have > a showdown with the ARIN community". Having said that, I (and > others) still think the idea has some merit and would be willing to > push on it on the IETF end, assuming we wouldn't get a repeat > reaction at future meetings for our efforts... the reasons, imho, that ARIN gave this the thumbs down was A) that it creates property rights, and B) has the IETF creating an other address registry out of whole cloth - not following the defined RIR creation process. For me, the first is fundamentally fatal. > > Note: AFAIK, no such reaction seemed to come out of APNIC or RIPE. > > I know that there is at least one person willing to resurrect the > ula-central document, but I (personally) don't want to invest cycles > in it if it's going to get a frosty reception in ARIN again. Been > there, done that. > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From randy at psg.com Sat Apr 22 02:50:59 2006 From: randy at psg.com (Randy Bush) Date: Fri, 21 Apr 2006 20:50:59 -1000 Subject: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <200604211256.k3LCu3V5011765@cichlid.raleigh.ibm.com> References: <200604211256.k3LCu3V5011765@cichlid.raleigh.ibm.com> Message-ID: <4449D253.2030700@psg.com> > Because today, people are a lot more network savvy, and they now > understand the potential value of getting real PI space. Moreover, > anyone who understands history, realizes that getting PI space may > become harder in the future, rather than easier. Consequently, it > would be a smart business move to get PI space ASAP, in case the rules > change down the road. i.e, a rather prudent investment. aka 'land rush' pfui! randy From christopher.morrow at gmail.com Sat Apr 22 11:34:50 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sat, 22 Apr 2006 11:34:50 -0400 Subject: [ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois In-Reply-To: References: Message-ID: <75cb24520604220834i148fd9c5l7af024f94140b9d8@mail.gmail.com> On 4/19/06, Divins, David wrote: > >I strongly oppose this provision. There is no reason to remove address > accountability from business orgs > > If Whois contains accurate contact/abuse info, how is this obscuring > accountability? If there is abuse report it to the contact. A > responsible ISP will handle that request. If the complaint is not > handled to your satisfaction-- block the ISP at the FW level like many > do to APNIC providers. Also, you are assuming these reassignments are In the world of larger network operations this is a non-starter... (blocking all of apnic at the 'firewall') We rely on abuse contacts working, some do some do not. I think that even i the current world we are stuck with the non-working (effectively anonymous) abuse@ problem. I'm, overall, undecided about this issue, residential privacy, though I believe businesses should not be treated as 'individuals'. Most residential assignments are /29 or smaller, so I'm not clear what we're protecting anyway. Was there any analysis done of the folks taht would be affected by a change in residential privacy requirements? -Chris From mpetach at netflight.com Sat Apr 22 14:49:04 2006 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 22 Apr 2006 11:49:04 -0700 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised In-Reply-To: <1c16a4870604211423r14132fdfv1f6dc224b1d2263f@mail.gmail.com> References: <63ac96a50604210942n6b97cc65k426a47f562f095cb@mail.gmail.com> <1c16a4870604211423r14132fdfv1f6dc224b1d2263f@mail.gmail.com> Message-ID: <63ac96a50604221149l2c870ce9t606ba07ad70c17f3@mail.gmail.com> On 4/21/06, Stacy Taylor wrote: > > Thank you, Jason. That is indeed what I was asking. Ah! OK, the longer explanation helped--I was indeed a bit confused by the shorthand version. ^_^; (Thanks, Jason!). Yes, modifying the proposal that way to factor out the common elements would work; I'd favour option 2 or option 4--operationally, I don't really see a difference between the two, except that with option 4 one has the potential for needing to clarify how the policing is handled--that is, the conditions under which the allocation can be revoked need to be clearly spelled out. After all, you wouldn't want me to be able to leak UUnet^WVerizon's backbone allocation from my home AS, and have ARIN revoke your allocation because of it. Matt (re-sending to ppml with correct 'from' address) -------------- next part -------------- An HTML attachment was scrubbed... URL: From weiler at tislabs.com Mon Apr 24 13:55:32 2006 From: weiler at tislabs.com (Sam Weiler) Date: Mon, 24 Apr 2006 13:55:32 -0400 (EDT) Subject: [ppml] Path forward on 2006-1 Message-ID: Based on the informal straw poll taken on Tuesday afternoon, it seems that the main point of contention in 2006-1 (Residential Customer Privacy) is about whether ARIN will continue to get city, state (or province), and postal code or not (or perhaps the objection was merely that the text I proposed is unclear on that question). Assuming that all address data may be suppressed, the only argument I heard in favor of ARIN continuing to get that data came from the ARIN staff. The slides in the meeting report are still password protected, but the meeting transcript says: "The proposal as written could be interpreted -- no longer provides different country information on the reassignment template. ARIN must continue to collect this information in order for forum verification, reassignment information and utilization. ARIN could not implement the proposal as written and continue to perform verification of reassignment information and utilization." I'd like to hear more from the staff about that need. To the extent that they need any individual customer data to verify use of an address block, I'd like to know why no other metric is sufficient, particularly some variant of those metrics already used for blocks which aren't SWIP'ed or pool address blocks. My suspicion, which I'd like staff to confirm, is that some variant on the existing metrics will suffice, and they do not need the city/state/postal code of individual users. -- Sam From plzak at arin.net Mon Apr 24 14:35:31 2006 From: plzak at arin.net (Ray Plzak) Date: Mon, 24 Apr 2006 14:35:31 -0400 Subject: [ppml] Path forward on 2006-1 In-Reply-To: Message-ID: <20060424183533.22A991FFB1@mercury.arin.net> > > Assuming that all address data may be suppressed, the only argument I > heard in favor of ARIN continuing to get that data came from the ARIN > staff. It was not an argument for or against the policy. The staff comment was that the information was still required for purpose of verification. The slides in the meeting report are still password protected, The slides are available as READ ONLY PPT or as PDF, both are working just fine. If you are still having problems reading them please send a note to webmaster so we can trouble shoot your particular problem. > but the meeting transcript says: > > "The proposal as written could be interpreted -- no longer > provides different country information on the reassignment > template. ARIN must continue to collect this information in > order for forum verification, reassignment information and > utilization. ARIN could not implement the proposal as > written and continue to perform verification of reassignment > information and utilization." > The transcript mangles the discrete points on the slide. For example, I believe the word "forum" in the transcript is the word "perform" on the slide. > I'd like to hear more from the staff about that need. To the extent > that they need any individual customer data to verify use of an > address block, I'd like to know why no other metric is sufficient, > particularly some variant of those metrics already used for blocks > which aren't SWIP'ed or pool address blocks. While not necessarily needed for verification of all address ranges, it is needed. I will not go into a discussion of how often or under which circumstances it is specifically used, but will say that it is necessary information needed by staff to perform their work. > > My suspicion, which I'd like staff to confirm, is that some variant on > the existing metrics will suffice, and they do not need the > city/state/postal code of individual users. City/state/postal code of individual users is a part of the metrics that are used by staff. We will confirm that we do use it. Ray > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From jason.schiller at mci.com Mon Apr 24 16:27:06 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Mon, 24 Apr 2006 16:27:06 -0400 (EDT) Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <20060422002805.GA1593@vacation.karoshi.com> Message-ID: Bill, Are you saying the right place to solve the private addressing issue is in the individual RIRs? I just want to be clear on this point so I can determine the best place to focus my efforts. I thought what I heard at the last ARIN meeting was that the ARIN policy on should not supercede and RFC on unique local addressing. This is troubling as it is my understing of the history of draft-ietf-ipv6-ula-central-01.txt is that in got 7/8s finished and then it died at the ARIN stage, but one of the things holding up the ARIN policy 2006-2 was that it really should be pursued in the IETF first. Many people who previuosly worked on draft-ietf-ipv6-ula-central-01.txt are not intrested in reviving the draft if it is just going to die at ateh ARIN stage. I would hate to invest time on the ARIN policy if people are not likely to accept it without an RFC. So the question I have for you and everyone is where is the best place to pursue this? ___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 Sat, 22 Apr 2006 bmanning at vacation.karoshi.com wrote: > On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: > > Cons: > > > > 1) ARIN pretty vocally shot down the document a year or more ago, and > > the IETF basically decided "we don't need this so badly as to have > > a showdown with the ARIN community". Having said that, I (and > > others) still think the idea has some merit and would be willing to > > push on it on the IETF end, assuming we wouldn't get a repeat > > reaction at future meetings for our efforts... > > the reasons, imho, that ARIN gave this the thumbs down was A) that > it creates property rights, and B) has the IETF creating an other > address registry out of whole cloth - not following the defined > RIR creation > process. For me, the first is fundamentally fatal. > > > > > Note: AFAIK, no such reaction seemed to come out of APNIC or RIPE. > > > > I know that there is at least one person willing to resurrect the > > ula-central document, but I (personally) don't want to invest cycles > > in it if it's going to get a frosty reception in ARIN again. Been > > there, done that. > > > > Thomas From jason.schiller at mci.com Mon Apr 24 17:46:28 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Mon, 24 Apr 2006 17:46:28 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: Message-ID: I too was frustrated by the comments that "ARIN does not set routing policy". It can be very difficult to advise your company to do the right thing for the good of the Internet when it is counter to good business practices. It is a little bit easier if one can hold up a "good IP stewardship policy" that most people are following. So should we re-charter ARIN to publish a non-binding "Routing Policy Guideline Manual (RPGM)" or should we just fold this into the NRPM? The other question is if this is the right forum? and if not, then what is the right forum? NANOG? only joint ARIN/NANOG meetings? Also, how does this relate to other regions? I am told that RIPE discusses routing policy. Should there be an NRO equilivent role with regard to global routing policy? ___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 Sat, 15 Apr 2006, Scott Leibrand wrote: > Date: Sat, 15 Apr 2006 09:23:49 -0400 (EDT) > From: Scott Leibrand > To: Owen DeLong > Cc: ppml at arin.net > Subject: [ppml] "Recommended Practices" procedure > > On 04/14/06 at 11:41pm -0700, Owen DeLong wrote: > > > > > as we also discussed at the ARIN XVII meeting, it would be useful for > > > some group to define guidelines for assignment policy that would clarify > > > the issues you raise. it seems that in ARIN policy is not the correct > > > place yet no other group comes to mind. anyway, as a rough suggestion, I > > > would say that end sites should get 4 to 8 times as much address space > > > assigned as they think they might use using today's networking techniques. > > > > > Perhaps we need a BCP track within ARIN for number resource utilization. > > A process similar to, but, potentially a bit less formal than, the IRPEP > > which would be used to develop "Recommended Practices for Number Resource > > Allocation, Assignment, and Utilization". > > I like this idea. > > > I agree this doesn't belong in policy, but, I do think that ARIN might be > > the right body to coalesce such information, at least on a regional basis. > > Perhaps we could use the existing policy process (or something similar and > parallel) to develop recommendations, though. Have folks submit > "Recommendation Proposals", which could be run through the PPML and > presented at ARIN meetings. Perhaps a lower standard of consensus would > be required for adoption... > > -Scott > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From jason.schiller at mci.com Mon Apr 24 18:04:33 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Mon, 24 Apr 2006 18:04:33 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call In-Reply-To: <4445CEA9.3040606@nic.ad.jp> Message-ID: Lea, On thing my team has been wrestling with is how we are going to divide up our PA aggrgegate to do internal aggregation for static customers. The basic problem is that aggregation and efficent use are at odds with each other. We are attempting to stike a balance by assigning blocks that are large enough to aggrgegate a large portion of space, but small enough such that if certain regions are under utilized, it will not prevent us from getting more IP space. This calculation is affected by the HD ratio unit size (/48 or /56) as well as the assignment size to customers. ___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, 19 Apr 2006, Izumi Okutani wrote: > Date: Wed, 19 Apr 2006 14:46:17 +0900 > From: Izumi Okutani > To: "ppml at arin.net" > Subject: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 > assignment and utilisation requirement - Last Call > > Hi Lea, > > > [snip] > > >>The current issues in JP are two: > >> > >> + Some impact over the existing LIRs are noted, expecially in > >> terms of expenses(1/2 LIRs face additional expenses of over > >> US$85,000). > > > > > > are these additional expenses one time costs? or do people feel there is > > some ongoing cost to dealing with multiple assignment sizes even after > > the supporting software is upgraded? > The cost mentioned above is one time. > > There will also be on going cost in terms of address fragmentation and > increased network complexity to support different sizes. These are not > necessary cost in terms of money, but considered as damage to the > existing service. > > How to address this problem is an issue for us, although I do also see > that we shouldn't be overly swayed by the short-term impact in > considering the long term future. > > > > >> + Few LIRs LIRs expressed concerns that classless addressing will > >> lose the benefit of IPv6 over IPv4. > >> i.e, simplicity of network design and service specification > >> > > I'd be happy to clarify if there is anything else I can explain. > Thanks for taking an interest in our situation. > > izumi > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From michel at arneill-py.sacramento.ca.us Mon Apr 24 18:28:16 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 24 Apr 2006 15:28:16 -0700 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] Message-ID: > Owen DeLong wrote: > As one of the coldest shoulders presented to ULA (in general), > I can say that assuming 2005-1 does not go down in some last-ditch > set of unanticipated flames, I would not oppose resurrection of > ULA-central because I believe the potential for economic-based > abuse is much less now. I will point out that the potential for abuse is still great as long as other RIRs don't have a PI policy. Michel. From plzak at arin.net Mon Apr 24 23:51:40 2006 From: plzak at arin.net (Ray Plzak) Date: Mon, 24 Apr 2006 23:51:40 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: Message-ID: <20060425035141.98CC81FFAA@mercury.arin.net> I hope you are not confusing RIPE (sometimes referred to as the RIPE community) and the RIPE NCC. The RIR is the RIPE NCC. From their respective web sites: 1. RIPE (R?seaux IP Europ?ens) is a collaborative forum open to all parties interested in wide area IP networks in Europe and beyond. The objective of RIPE is to ensure the administrative and technical coordination necessary to enable the operation of a pan-European IP network. 2. The RIPE NCC is one of five Regional Internet Registries (RIRs) providing Internet resource allocations, registration services and co-ordination activities that support the operation of the Internet globally. The RIPE NCC also provides services for the benefit of the Internet community at large. These services include: * Development and maintenance of the RIPE Whois Database * Administrative support for the RIPE community. Currently there is a RIPE meeting in progress, not a RIPE NCC meeting. Thus it is perfectly understandable, given the above, that RIPE would discuss routing policy. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Jason Schiller (schiller at uu.net) > Sent: Monday, April 24, 2006 5:46 PM > To: Scott Leibrand > Cc: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > I too was frustrated by the comments that "ARIN does not set routing > policy". > > It can be very difficult to advise your company to do the right thing for > the good of the Internet when it is counter to good business > practices. It is a little bit easier if one can hold up a "good IP > stewardship policy" that most people are following. > > So should we re-charter ARIN to publish a non-binding "Routing Policy > Guideline Manual (RPGM)" or should we just fold this into the NRPM? > > The other question is if this is the right forum? and if not, then what > is the right forum? NANOG? only joint ARIN/NANOG meetings? > > Also, how does this relate to other regions? I am told that RIPE > discusses routing policy. Should there be an NRO equilivent role with > regard to global routing policy? > > > ___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 Sat, 15 Apr 2006, Scott Leibrand wrote: > > > Date: Sat, 15 Apr 2006 09:23:49 -0400 (EDT) > > From: Scott Leibrand > > To: Owen DeLong > > Cc: ppml at arin.net > > Subject: [ppml] "Recommended Practices" procedure > > > > On 04/14/06 at 11:41pm -0700, Owen DeLong wrote: > > > > > > > as we also discussed at the ARIN XVII meeting, it would be useful > for > > > > some group to define guidelines for assignment policy that would > clarify > > > > the issues you raise. it seems that in ARIN policy is not the > correct > > > > place yet no other group comes to mind. anyway, as a rough > suggestion, I > > > > would say that end sites should get 4 to 8 times as much address > space > > > > assigned as they think they might use using today's networking > techniques. > > > > > > > Perhaps we need a BCP track within ARIN for number resource > utilization. > > > A process similar to, but, potentially a bit less formal than, the > IRPEP > > > which would be used to develop "Recommended Practices for Number > Resource > > > Allocation, Assignment, and Utilization". > > > > I like this idea. > > > > > I agree this doesn't belong in policy, but, I do think that ARIN might > be > > > the right body to coalesce such information, at least on a regional > basis. > > > > Perhaps we could use the existing policy process (or something similar > and > > parallel) to develop recommendations, though. Have folks submit > > "Recommendation Proposals", which could be run through the PPML and > > presented at ARIN meetings. Perhaps a lower standard of consensus would > > be required for adoption... > > > > -Scott > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From pekkas at netcore.fi Tue Apr 25 02:10:43 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 25 Apr 2006 09:10:43 +0300 (EEST) Subject: [ppml] [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: Hi, On Fri, 21 Apr 2006, Ruchti, Marcus wrote: > I don't think flapping routes will increase due to the assignments > of PI space, as in the most cases ISP's are requesting those for > customers and offers managed multihoming solutions. So announcing > these routes into BGP is the responsibility of an ISP. First off: there has been some discussion whether 200K routes is a problem or not. If the numbers stayed at that level (how can we ensure that?), that wouldn't be a huge problem. Bigger one is dynamicity. Huston's study indicated that there are folks whose BGP announcements flap (due to TE) intentionally 1000's of times a day. Multiply that by the number of sites (and add sBGP or friends to the stew) and you may start thinking that your DFZ router might have better things to do than process that cruft. And now responding to your specific comment, I do not agree with "So announcing these routes into BGP is the responsibility of an ISP." -- the _sites_ decide how they want to advertise; the biggest decision of the ISP is whether it does BGP flap damping for these or not. Virtually all multihomers use their own AS number -- agree? If you agree, I guess what you're saying is that in most cases the ISPs set up the AS numbers and the multihoming at customer's equipment, customer's premises or colo, customer's AS number, etc.? Indeed, I believe in significant number of cases, a consultant (whether from one of the ISPs or an outsider -- I'd personally prefer an outsider as (s)he wouldn't have a conflict of interest) sets up the multihoming setup. But that doesn't preclude said consultants, other consultants, or local network engineering staff from adjusting the set-up later on. If one of the ISPs had sole management of the setup, that would seem somewhat at odds with the provider independence principle. -- 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 bmanning at vacation.karoshi.com Tue Apr 25 04:12:10 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 25 Apr 2006 08:12:10 +0000 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: References: <20060422002805.GA1593@vacation.karoshi.com> Message-ID: <20060425081210.GH1014@vacation.karoshi.com.> On Mon, Apr 24, 2006 at 04:27:06PM -0400, Jason Schiller (schiller at uu.net) wrote: > Bill, > > Are you saying the right place to solve the private addressing issue is in > the individual RIRs? perhaps i was unclear. the ULA proposal from the IETF create property rights in IP address space, a concept that to date, is antithical to the RIR premise that IP space is roughly analogous to frequencies... e.g. can I OWN the frequency band between 10.8GHz and 11.2Ghz and require anyone who uses it to pay me royalties on a global basis? the IETF proposal allows entities to claim ownership, via first come, first served, of IP space. There is some precident at least in the US system of law, which argues against the ability to own numbers. My fears may be unfounded in this regard. but the ULA central proposal does create yet another registry, the "central" thing that is supposed to track who is holding what. And there is no plan to provide a viaable businsess model for such a "central" holder. And there is no current way that "central" can or would coordinate with the other RIRs. -MY- assertion is that there is or should be no distinction on an address delegation... the PI/PA debate is or should be pointless. You get a delegation or not. You can chose to make subsiquent delegations from your delegated space or not. And it is reasonable to place conditions on a delegation such that it is recoverable... presuming the horse has not left the barn. that said, ARIN policy is created through the the open policy process. if you -WANT- to add more policies, go for it. I'd prefer to revamp most of the policies and come up wiht a few core things and not build up a big policy analysis group. --bill > > I just want to be clear on this point so I can determine the best place to > focus my efforts. > > I thought what I heard at the last ARIN meeting was that the ARIN policy > on should not supercede and RFC on unique local addressing. > > This is troubling as it is my understing of the history of > draft-ietf-ipv6-ula-central-01.txt is that in got 7/8s finished and then > it died at the ARIN stage, but one of the things holding up the ARIN > policy 2006-2 was that it really should be pursued in the IETF first. > > Many people who previuosly worked on draft-ietf-ipv6-ula-central-01.txt > are not intrested in reviving the draft if it is just going to die at ateh > ARIN stage. I would hate to invest time on the ARIN policy if people are > not likely to accept it without an RFC. > > So the question I have for you and everyone is where is the best place to > pursue this? > > ___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 Sat, 22 Apr 2006 bmanning at vacation.karoshi.com wrote: > > > On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: > > > Cons: > > > > > > 1) ARIN pretty vocally shot down the document a year or more ago, and > > > the IETF basically decided "we don't need this so badly as to have > > > a showdown with the ARIN community". Having said that, I (and > > > others) still think the idea has some merit and would be willing to > > > push on it on the IETF end, assuming we wouldn't get a repeat > > > reaction at future meetings for our efforts... > > > > the reasons, imho, that ARIN gave this the thumbs down was A) that > > it creates property rights, and B) has the IETF creating an other > > address registry out of whole cloth - not following the defined > > RIR creation > > process. For me, the first is fundamentally fatal. > > > > > > > > Note: AFAIK, no such reaction seemed to come out of APNIC or RIPE. > > > > > > I know that there is at least one person willing to resurrect the > > > ula-central document, but I (personally) don't want to invest cycles > > > in it if it's going to get a frosty reception in ARIN again. Been > > > there, done that. > > > > > > Thomas > From bmanning at vacation.karoshi.com Tue Apr 25 04:21:01 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 25 Apr 2006 08:21:01 +0000 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: <20060425082101.GI1014@vacation.karoshi.com.> Apr 24, 2006 at 05:46:28PM -0400, Jason Schiller (schiller at uu.net) wrote: > I too was frustrated by the comments that "ARIN does not set routing > policy". arin has -never set routing policy for others because arin only runs its own routers. i'm sure that if you could convince arin to run your routers, it would implement a routing policy for you. :) > It can be very difficult to advise your company to do the right thing for > the good of the Internet when it is counter to good business > practices. It is a little bit easier if one can hold up a "good IP > stewardship policy" that most people are following. this is really passing the buck Jason. Asking ARIN to be your backstop instead of coming up with your own "good IP stewardship policy" is placing an unwanted burden on ARIN. > So should we re-charter ARIN to publish a non-binding "Routing Policy > Guideline Manual (RPGM)" or should we just fold this into the NRPM? i'd say neither... > The other question is if this is the right forum? and if not, then what > is the right forum? NANOG? only joint ARIN/NANOG meetings? > > Also, how does this relate to other regions? I am told that RIPE > discusses routing policy. Should there be an NRO equilivent role with > regard to global routing policy? RIPE does ... but it also forces its members to do other things that ARIN members might find objectionable. unclear what LACNIC, AFRNIC and APNIC do wrt enforcing routing policy... but there does seem to be some interest in RIRs -signing- delegations. while this does not set the routing policy, it does disambiguate prefix origin. > > > ___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 Sat, 15 Apr 2006, Scott Leibrand wrote: > > > Date: Sat, 15 Apr 2006 09:23:49 -0400 (EDT) > > From: Scott Leibrand > > To: Owen DeLong > > Cc: ppml at arin.net > > Subject: [ppml] "Recommended Practices" procedure > > > > On 04/14/06 at 11:41pm -0700, Owen DeLong wrote: > > > > > > > as we also discussed at the ARIN XVII meeting, it would be useful for > > > > some group to define guidelines for assignment policy that would clarify > > > > the issues you raise. it seems that in ARIN policy is not the correct > > > > place yet no other group comes to mind. anyway, as a rough suggestion, I > > > > would say that end sites should get 4 to 8 times as much address space > > > > assigned as they think they might use using today's networking techniques. > > > > > > > Perhaps we need a BCP track within ARIN for number resource utilization. > > > A process similar to, but, potentially a bit less formal than, the IRPEP > > > which would be used to develop "Recommended Practices for Number Resource > > > Allocation, Assignment, and Utilization". > > > > I like this idea. > > > > > I agree this doesn't belong in policy, but, I do think that ARIN might be > > > the right body to coalesce such information, at least on a regional basis. > > > > Perhaps we could use the existing policy process (or something similar and > > parallel) to develop recommendations, though. Have folks submit > > "Recommendation Proposals", which could be run through the PPML and > > presented at ARIN meetings. Perhaps a lower standard of consensus would > > be required for adoption... > > > > -Scott > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Tue Apr 25 04:52:56 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 25 Apr 2006 09:52:56 +0100 Subject: [ppml] Path forward on 2006-1 In-Reply-To: Message-ID: > I'd like to hear more from the staff about that need. As far as I am concerned, none of the ARIN policies limit staff activities unless they explicitly state that they do. The RS agreement and NDA is the document that governs what ARIN staff can request from applicants. The RS agreement explicitly states: Evaluation may require additional documentation to support the application such as, but not limited to, ... And ARIN will sign a non-disclosure agreement relating to the information submitted to support an application. We really should keep these two issues separate and not muddy the waters. On the one hand it is suggested that we change the policies regarding the PUBLISHING OF THE WHOIS DIRECTORY. On the other hand, there is some talk about how changes to the RS agreement should be handled. The PUBLISHED WHOIS DIRECTORY has always contained a subset of the information that is given to ARIN. Nothing new about that. --Michael Dillon From Michael.Dillon at btradianz.com Tue Apr 25 05:03:04 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 25 Apr 2006 10:03:04 +0100 Subject: [ppml] Path forward on 2006-1 In-Reply-To: <20060424183533.22A991FFB1@mercury.arin.net> Message-ID: "Ray Plzak" wrote on 24/04/2006 19:35:31: > While not necessarily needed for verification of all address ranges, it is > needed. I will not go into a discussion of how often or under which > circumstances it is specifically used, but will say that it is necessary > information needed by staff to perform their work. I am surprised that you would post this to a public policy discussion of changes to the WHOIS publishing policy. Maybe you got sucked in by BAD HABIT people have of referring to policies by random numbers such as 2006-1 instead of speaking to the substance. However, it is not any business of the ARIN staff what information we choose to publish in the WHOIS directory and it has no impact on the staff's ability to to their job outside of the people who deal with operations and development of the whois directory. Again, ARIN staff can already get more complete information than WHOIS publishing policy specifies. On more than one occasion I have supplied a database with EVERY assigned netblock including those smaller than /29. The Residential Privacy policy refers only to the information published in the whois directory and has ABSOLUTELY NOTHING TO DO WITH ADDRESS APPLICATIONS. --Michael Dillon From Michael.Dillon at btradianz.com Tue Apr 25 05:06:25 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 25 Apr 2006 10:06:25 +0100 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: Message-ID: > So the question I have for you and everyone is where is the best place to > pursue this? Everywhere at once. Throw the spaghetti to the ceiling and see where it sticks. The IETF has to be involved in specifying new addressing models but they don't seem to want to act without some clear view from RIRs and network operators. In other words, you can probably get some traction if you chase this at NANOG, ARIN and IETF meetings. --Michael Dillon From jeroen at unfix.org Tue Apr 25 08:48:40 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 25 Apr 2006 14:48:40 +0200 Subject: [ppml] [address-policy-wg] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <6.2.3.4.2.20060425100335.05206ef8@mail.dante.org.uk> References: <054601c66496$60f6b210$3712fea9@ssprunk> <088201c664ec$d991ac60$3712fea9@ssprunk> <6.2.3.4.2.20060425100335.05206ef8@mail.dante.org.uk> Message-ID: <1145969320.20018.36.camel@firenze.zurich.ibm.com> On Tue, 2006-04-25 at 10:15 +0100, Tim Streater wrote: > At 03:39 21/04/2006, Stephen Sprunk wrote: [..] > >OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two > >pipes or tunnels), and there's not all that many companies doing > >it. It's not growing much either. The doors are already wide open > >for a land rush and >>nobody is taking ARIN up on it. Why does > >everyone assume it'll happen with v6 if it's not happening with v4, > >which _is_ useful today? > > This is perhaps the most pertinent question to have been asked during > this thread and I'm not sure I saw any answer to it. So I'll ask it > again. What is the evidence that using v4's PI policy for v6 would > lead to a land rush of catastrophic proportions and the routing table > becoming huge? All I've seen so far is hand-waving doomsayers. There is no evidence, but it might just happen ;) Maybe not today, but maybe in a couple of years. IPv6 is intended to be there for the coming decades, not for tomorrow. > Remember that to get PI space at all you have to know what you are doing, > and you have to justify the usage. And the process takes a certain > time. All of these would tend to discourage the casual enquirer. This is indeed the only limit for both IPv6 PA and the new to be coming PI space: you need to know what you are doing. Thus upto the time that somebody writes up a "HOWTO: Multihoming at home" document it should not cause much issues. That said, when/if a landrush would break out, people are still in control of their own routers and it will become very easy to start filtering certain small prefixes. This happened also in IPv4 (try announcing a /28 or so ;). At that point, people who have the cash can keep on doing it that way, other folks will have to resort to different methods like shim6/hip/sctp and a number of other proposals. In the end one will still need "PI" space at most sites anyway. As it is the sole method of making sure that one can stick IP addresses in certain important places like firewall rules and DNS without ever having to think about it again or having to remember that you stuck them there. This is where the above methods come in, they will make the packet, while traveling over the internet be the upstreams src/dst, while being "PI" on the edges. This solves all the issues at hand. For the time being though people can happily use IPv6 PI space in the way they are 'used' to in IPv4. This gives enough time for the new methods to become crystal clear and cover all the known problemspaces so that end-sites can use them happily ever after. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From dlw+arin at tellme.com Tue Apr 25 09:42:40 2006 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 25 Apr 2006 06:42:40 -0700 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <20060425081210.GH1014@vacation.karoshi.com.> References: <20060422002805.GA1593@vacation.karoshi.com> <20060425081210.GH1014@vacation.karoshi.com.> Message-ID: <20060425134240.GC16281@shell01.corp.tellme.com> On Tue, Apr 25, 2006 at 08:12:10AM +0000, bmanning at vacation.karoshi.com wrote: > On Mon, Apr 24, 2006 at 04:27:06PM -0400, Jason Schiller (schiller at uu.net) wrote: > perhaps i was unclear. the ULA proposal from the IETF > create property rights in IP address space, a concept that > to date, is antithical to the RIR premise that IP space > is roughly analogous to frequencies... e.g. can I OWN > the frequency band between 10.8GHz and 11.2Ghz and require > anyone who uses it to pay me royalties on a global basis? I haven't read the IETF proposal, but I'm hoping that we can simply link this hypothetical internal infrastructure allocation to holding an AS. In that way, there's no ownership created, since you certainly don't own an AS number. The RIRs would still be the allocators of space out of the global reserved block for this purpose: they simply provide stewardship of the chunk associated with the ASNs allocated to them. Sounds like I better go read the draft. I agree that ownership rights would be a problem, but I think there must be a way to link this to other resources such that the RIR stewardship concept applies. -David From marla_azinger at eli.net Tue Apr 25 12:22:40 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Tue, 25 Apr 2006 09:22:40 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D0A@wava00s2ke2k01.corp.pvt> What I see frustrating here is that everyone agrees we need some sort of "internet community agreement" that addresses V6 routing. I hear alot of people asking for this, including myself. Yet I dont hear any specific forum stepping forward to help facilitate this need. Saying Jason is passing the buck is really not true. I see him as one of the people yelling outloud "hey I'm here to help, but a need a forum to facilitate." I ask myself "why does it appear that all known forums" are unwilling to touch this issue? I keep hearing "its not our charter". When I hear this "reason" I wonder again, do these charters exist as a hard bound document and if so, maybe it should be re-written. Or is there a "stewardship and spirit of the charter" that exists that we just need to acknowledge? I also keep hearing "work the issue out between you and the other providers". I agree, great idea, but we need a forum of facilitation to do this. Back door deals are what come from "agreements" made without a community forum and this can leave certain businesses out in the cold. I dont see this as a good internet community minded solution. So what then? Do we create yet another Task Force? Or just keep pointing our fingers in a circle from Forum to Forum? The lack of facilitation in this issue needs to stop. We need to write some form of best practice for routing V6. Maybe it doesnt need to be an ARIN sanctioned policy, but I suggest we support time, document creation and discussion at a joint ARIN/NANOG meeting. In good stewardship and spirit of the Internet I think it is our responsiblity to support the creation of a "best practice document" that is created by the community, not by back door deals. Regards Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of bmanning at vacation.karoshi.com Sent: Tuesday, April 25, 2006 1:21 AM To: Jason Schiller (schiller at uu.net) Cc: ppml at arin.net Subject: Re: [ppml] "Recommended Practices" procedure Apr 24, 2006 at 05:46:28PM -0400, Jason Schiller (schiller at uu.net) wrote: > I too was frustrated by the comments that "ARIN does not set routing > policy". arin has -never set routing policy for others because arin only runs its own routers. i'm sure that if you could convince arin to run your routers, it would implement a routing policy for you. :) > It can be very difficult to advise your company to do the right thing for > the good of the Internet when it is counter to good business > practices. It is a little bit easier if one can hold up a "good IP > stewardship policy" that most people are following. this is really passing the buck Jason. Asking ARIN to be your backstop instead of coming up with your own "good IP stewardship policy" is placing an unwanted burden on ARIN. > So should we re-charter ARIN to publish a non-binding "Routing Policy > Guideline Manual (RPGM)" or should we just fold this into the NRPM? i'd say neither... > The other question is if this is the right forum? and if not, then what > is the right forum? NANOG? only joint ARIN/NANOG meetings? > > Also, how does this relate to other regions? I am told that RIPE > discusses routing policy. Should there be an NRO equilivent role with > regard to global routing policy? RIPE does ... but it also forces its members to do other things that ARIN members might find objectionable. unclear what LACNIC, AFRNIC and APNIC do wrt enforcing routing policy... but there does seem to be some interest in RIRs -signing- delegations. while this does not set the routing policy, it does disambiguate prefix origin. > > > ___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 Sat, 15 Apr 2006, Scott Leibrand wrote: > > > Date: Sat, 15 Apr 2006 09:23:49 -0400 (EDT) > > From: Scott Leibrand > > To: Owen DeLong > > Cc: ppml at arin.net > > Subject: [ppml] "Recommended Practices" procedure > > > > On 04/14/06 at 11:41pm -0700, Owen DeLong wrote: > > > > > > > as we also discussed at the ARIN XVII meeting, it would be useful for > > > > some group to define guidelines for assignment policy that would clarify > > > > the issues you raise. it seems that in ARIN policy is not the correct > > > > place yet no other group comes to mind. anyway, as a rough suggestion, I > > > > would say that end sites should get 4 to 8 times as much address space > > > > assigned as they think they might use using today's networking techniques. > > > > > > > Perhaps we need a BCP track within ARIN for number resource utilization. > > > A process similar to, but, potentially a bit less formal than, the IRPEP > > > which would be used to develop "Recommended Practices for Number Resource > > > Allocation, Assignment, and Utilization". > > > > I like this idea. > > > > > I agree this doesn't belong in policy, but, I do think that ARIN might be > > > the right body to coalesce such information, at least on a regional basis. > > > > Perhaps we could use the existing policy process (or something similar and > > parallel) to develop recommendations, though. Have folks submit > > "Recommendation Proposals", which could be run through the PPML and > > presented at ARIN meetings. Perhaps a lower standard of consensus would > > be required for adoption... > > > > -Scott > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From tli at tropos.com Tue Apr 25 13:00:21 2006 From: tli at tropos.com (Tony Li) Date: Tue, 25 Apr 2006 10:00:21 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D0A@wava00s2ke2k01.corp.pvt> Message-ID: <008e01c66889$bcb318e0$b101a8c0@tropos.com> > What I see frustrating here is that everyone agrees we need > some sort of "internet community agreement" that addresses V6 > routing. I hear alot of people asking for this, including > myself. Yet I dont hear any specific forum stepping forward > to help facilitate this need. What you're asking for is a "routing and addressing architecture". Currently, it's really the purview of the IETF, except that they've basically abdicated the role. This creates a vacuum, which, as you note cries out to be filled. There are multiple ways to make progress here, but my favorite is for ARIN to simply push the problem back to the IETF and insist on a sensible and scalable solution. Tony From marla_azinger at eli.net Tue Apr 25 13:22:54 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Tue, 25 Apr 2006 10:22:54 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A543@wava00s2ke2k01.corp.pvt> Tony- That would be nice if IETF could do this. The second issue we face is, we need a solution now, not in a year. Despite some beliefs that V6 isnt going anywhere, there are companies right now starting to deploy to large customers on V6. Regards Marla -----Original Message----- From: Tony Li [mailto:tli at tropos.com] Sent: Tuesday, April 25, 2006 10:00 AM To: Azinger, Marla; bmanning at vacation.karoshi.com; 'Jason Schiller (schiller at uu.net)' Cc: ppml at arin.net Subject: RE: [ppml] "Recommended Practices" procedure > What I see frustrating here is that everyone agrees we need > some sort of "internet community agreement" that addresses V6 > routing. I hear alot of people asking for this, including > myself. Yet I dont hear any specific forum stepping forward > to help facilitate this need. What you're asking for is a "routing and addressing architecture". Currently, it's really the purview of the IETF, except that they've basically abdicated the role. This creates a vacuum, which, as you note cries out to be filled. There are multiple ways to make progress here, but my favorite is for ARIN to simply push the problem back to the IETF and insist on a sensible and scalable solution. Tony From pesherb at yahoo.com Tue Apr 25 13:56:49 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Tue, 25 Apr 2006 10:56:49 -0700 (PDT) Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <20060425081210.GH1014@vacation.karoshi.com.> Message-ID: <20060425175649.42762.qmail@web54709.mail.yahoo.com> >... the PI/PA debate is or should be pointless. Perhaps a consesus definition of an IP address could help, e.g.: An IP address is a unique topological identifier of the interface where the number of bits in the address determines the version of IP. This would remove the ownership topic because no one owns the whole or a part of any particular version of the protocol. Peter --- bmanning at vacation.karoshi.com wrote: > On Mon, Apr 24, 2006 at 04:27:06PM -0400, Jason Schiller (schiller at uu.net) wrote: > > Bill, > > > > Are you saying the right place to solve the private addressing issue is in > > the individual RIRs? > > perhaps i was unclear. the ULA proposal from the IETF > create property rights in IP address space, a concept that > to date, is antithical to the RIR premise that IP space > is roughly analogous to frequencies... e.g. can I OWN > the frequency band between 10.8GHz and 11.2Ghz and require > anyone who uses it to pay me royalties on a global basis? > > the IETF proposal allows entities to claim ownership, via > first come, first served, of IP space. There is some precident > at least in the US system of law, which argues against the > ability to own numbers. My fears may be unfounded in this > regard. > > but the ULA central proposal does create yet another registry, > the "central" thing that is supposed to track who is holding what. > And there is no plan to provide a viaable businsess model for such > a "central" holder. And there is no current way that "central" > can or would coordinate with the other RIRs. > > -MY- assertion is that there is or should be no distinction > on an address delegation... the PI/PA debate is or should be > pointless. You get a delegation or not. You can chose to make > subsiquent delegations from your delegated space or not. > And it is reasonable to place conditions on a delegation such that > it is recoverable... presuming the horse has not left the barn. > > that said, ARIN policy is created through the the open policy > process. if you -WANT- to add more policies, go for it. > I'd prefer to revamp most of the policies and come up wiht > a few core things and not build up a big policy analysis group. > > --bill > > > > > I just want to be clear on this point so I can determine the best place to > > focus my efforts. > > > > I thought what I heard at the last ARIN meeting was that the ARIN policy > > on should not supercede and RFC on unique local addressing. > > > > This is troubling as it is my understing of the history of > > draft-ietf-ipv6-ula-central-01.txt is that in got 7/8s finished and then > > it died at the ARIN stage, but one of the things holding up the ARIN > > policy 2006-2 was that it really should be pursued in the IETF first. > > > > Many people who previuosly worked on draft-ietf-ipv6-ula-central-01.txt > > are not intrested in reviving the draft if it is just going to die at ateh > > ARIN stage. I would hate to invest time on the ARIN policy if people are > > not likely to accept it without an RFC. > > > > So the question I have for you and everyone is where is the best place to > > pursue this? > > > > ___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 Sat, 22 Apr 2006 bmanning at vacation.karoshi.com wrote: > > > > > On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: > > > > Cons: > > > > > > > > 1) ARIN pretty vocally shot down the document a year or more ago, and > > > > the IETF basically decided "we don't need this so badly as to have > > > > a showdown with the ARIN community". Having said that, I (and > > > > others) still think the idea has some merit and would be willing to > > > > push on it on the IETF end, assuming we wouldn't get a repeat > > > > reaction at future meetings for our efforts... > > > > > > the reasons, imho, that ARIN gave this the thumbs down was A) that > > > it creates property rights, and B) has the IETF creating an other > > > address registry out of whole cloth - not following the defined > > > RIR creation > > > process. For me, the first is fundamentally fatal. > > > > > > > > > > > Note: AFAIK, no such reaction seemed to come out of APNIC or RIPE. > > > > > > > > I know that there is at least one person willing to resurrect the > > > > ula-central document, but I (personally) don't want to invest cycles > > > > in it if it's going to get a frosty reception in ARIN again. Been > > > > there, done that. > > > > > > > > Thomas > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mpetach at netflight.com Tue Apr 25 14:56:27 2006 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 25 Apr 2006 11:56:27 -0700 Subject: [ppml] [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <63ac96a50604251156i5681cbfbl77c49ccd20254dd1@mail.gmail.com> On 4/24/06, Pekka Savola wrote: > > Hi, > > On Fri, 21 Apr 2006, Ruchti, Marcus wrote: > > I don't think flapping routes will increase due to the assignments > > of PI space, as in the most cases ISP's are requesting those for > > customers and offers managed multihoming solutions. So announcing > > these routes into BGP is the responsibility of an ISP. > > First off: there has been some discussion whether 200K routes is a > problem or not. If the numbers stayed at that level (how can we > ensure that?), that wouldn't be a huge problem. Bigger one is > dynamicity. Huston's study indicated that there are folks whose BGP > announcements flap (due to TE) intentionally 1000's of times a day. > Multiply that by the number of sites (and add sBGP or friends to the > stew) and you may start thinking that your DFZ router might have > better things to do than process that cruft. BGP flap dampening is already well understood for limiting the impact of flapping routes on your CPU, if that's a concern; it has no bearing on address allocation policy decisionmaking. And configuring dampening is up to each _recipient_ network, and is not something that should be codified into an address allocation policy, which is targetted at the _originating_ network. Let's stick to the topic at hand, which is how to craft a useful address allocation policy which allows for provider indepent address allocations, while at the same time showing good stewardship of the overall address pool. The policy cannot allow itself to be shaped by the least-capable routers, or we'll be chaining ourselves to the past,unable to make adequate forward progress so long as there's any network out there that's still running old hardware that's unwilling to upgrade. I agree we need to be reasonable--but please, let's not "dumb down" the v6 internet just because some people aren't willing to step up to the plate and upgrade their routers when needed. Provider independence is here already, period. It's too late to try to put the horse back in the barn--what we *can* try to do is craft a well-thought-out policy 'bridle' for it, and then let it start running (to abuse a metaphor horribly). Trying to stop provider independent addressing in IPv6 is simply another way of saying 'IPv6 addressing is broken, let's just stick with IPv4 instead' -- because that's what the practical outcome is. Any addressing scheme that tries to deny the need for provider independent addressing is less capable for businesses than what they have today in the IPv4 world, and will therefore not be used. So. Given that PI allocations are going to happen in IPv6 just as they have in IPv4, let's put all the rest of the grumbling about it aside, acknowledge the reality of the situation, and simply agree that as a starting point, issuing a /48 out of a reserved /44 to each multi-homed, non-transit-service-providing network which applies and demonstrates it has met the requirements for being multi-homed and obtaining its own AS, is reasonable--if adjustments to the policy are needed, they can be applied in the future as needed, just as we've done in the IPv4 world. I *do* agree that stipulating that only the largest possible aggregate assigned to a given AS *should be* announced by the AS is a reasonable addition to the policy to help encourage aggregation, and prevent stupid routing mistakes like this: * 198.144.160.0/20 195.66.224.82 0 4513 174 6983 8051 i * 198.144.172.0 195.66.224.82 0 4513 701 8051 i (real-world example pulled from route-views; the /24 is announced by the same originating AS, but is not connected to or directly reachable from the network that announces the /20 aggregate, as was pointed out by the end-site when their /24 more specific was filtered out at one point.) That is, if you have discontiguous networks, they should each obtain their own AS, and should pay the registration fees for that AS and the associated IP aggregate which it will announce. I don't see why the discussion is dragging out for so long. This isn't rocket science. Let's just nail the policy down, and move on with more productive work. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Apr 25 14:57:51 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Apr 2006 11:57:51 -0700 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <20060425175649.42762.qmail@web54709.mail.yahoo.com> References: <20060425175649.42762.qmail@web54709.mail.yahoo.com> Message-ID: <94C94B9F882424A305BB78A3@imac-en0.delong.sj.ca.us> However, in the long run, tying IP Address to Topology as a definition would further cement what I believe is an error in the protocol design. The IP address should be strictly an End System Identifier. Overloading topology onto it is part of why we are worried about scaling limits in routing tables. Owen --On April 25, 2006 10:56:49 AM -0700 Peter Sherbin wrote: >> ... the PI/PA debate is or should be pointless. > > Perhaps a consesus definition of an IP address could help, e.g.: > An IP address is a unique topological identifier of the interface where > the number of bits in the address determines the version of IP. > > This would remove the ownership topic because no one owns the whole or a > part of any particular version of the protocol. > > Peter > > > --- bmanning at vacation.karoshi.com wrote: > >> On Mon, Apr 24, 2006 at 04:27:06PM -0400, Jason Schiller >> (schiller at uu.net) wrote: >> > Bill, >> > >> > Are you saying the right place to solve the private addressing issue >> > is in the individual RIRs? >> >> perhaps i was unclear. the ULA proposal from the IETF >> create property rights in IP address space, a concept that >> to date, is antithical to the RIR premise that IP space >> is roughly analogous to frequencies... e.g. can I OWN >> the frequency band between 10.8GHz and 11.2Ghz and require >> anyone who uses it to pay me royalties on a global basis? >> >> the IETF proposal allows entities to claim ownership, via >> first come, first served, of IP space. There is some precident >> at least in the US system of law, which argues against the >> ability to own numbers. My fears may be unfounded in this >> regard. >> >> but the ULA central proposal does create yet another registry, >> the "central" thing that is supposed to track who is holding what. >> And there is no plan to provide a viaable businsess model for such >> a "central" holder. And there is no current way that "central" >> can or would coordinate with the other RIRs. >> >> -MY- assertion is that there is or should be no distinction >> on an address delegation... the PI/PA debate is or should be >> pointless. You get a delegation or not. You can chose to make >> subsiquent delegations from your delegated space or not. >> And it is reasonable to place conditions on a delegation such that >> it is recoverable... presuming the horse has not left the barn. >> >> that said, ARIN policy is created through the the open policy >> process. if you -WANT- to add more policies, go for it. >> I'd prefer to revamp most of the policies and come up wiht >> a few core things and not build up a big policy analysis group. >> >> --bill >> >> > >> > I just want to be clear on this point so I can determine the best >> > place to focus my efforts. >> > >> > I thought what I heard at the last ARIN meeting was that the ARIN >> > policy on should not supercede and RFC on unique local addressing. >> > >> > This is troubling as it is my understing of the history of >> > draft-ietf-ipv6-ula-central-01.txt is that in got 7/8s finished and >> > then it died at the ARIN stage, but one of the things holding up the >> > ARIN policy 2006-2 was that it really should be pursued in the IETF >> > first. >> > >> > Many people who previuosly worked on draft-ietf-ipv6-ula-central-01.txt >> > are not intrested in reviving the draft if it is just going to die at >> > ateh ARIN stage. I would hate to invest time on the ARIN policy if >> > people are not likely to accept it without an RFC. >> > >> > So the question I have for you and everyone is where is the best place >> > to pursue this? >> > >> > ___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 Sat, 22 Apr 2006 bmanning at vacation.karoshi.com wrote: >> > >> > > On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: >> > > > Cons: >> > > > >> > > > 1) ARIN pretty vocally shot down the document a year or more ago, >> > > > and the IETF basically decided "we don't need this so badly as to >> > > > have a showdown with the ARIN community". Having said that, I >> > > > (and others) still think the idea has some merit and would be >> > > > willing to push on it on the IETF end, assuming we wouldn't get >> > > > a repeat reaction at future meetings for our efforts... >> > > >> > > the reasons, imho, that ARIN gave this the thumbs down was A) that >> > > it creates property rights, and B) has the IETF creating an other >> > > address registry out of whole cloth - not following the defined >> > > RIR creation >> > > process. For me, the first is fundamentally fatal. >> > > >> > > > >> > > > Note: AFAIK, no such reaction seemed to come out of APNIC or >> > > > RIPE. >> > > > >> > > > I know that there is at least one person willing to resurrect the >> > > > ula-central document, but I (personally) don't want to invest >> > > > cycles in it if it's going to get a frosty reception in ARIN >> > > > again. Been there, done that. >> > > > >> > > > Thomas >> > >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From pesherb at yahoo.com Tue Apr 25 15:22:45 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Tue, 25 Apr 2006 12:22:45 -0700 (PDT) Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <94C94B9F882424A305BB78A3@imac-en0.delong.sj.ca.us> Message-ID: <20060425192245.75649.qmail@web54702.mail.yahoo.com> Removing topology from the definition changes the current Internet hierarchy. Then the immediate next step would be defining the architecture where topology does not matter(?) Peter --- Owen DeLong wrote: > However, in the long run, tying IP Address to Topology as a definition would > further cement what I believe is an error in the protocol design. The > IP address should be strictly an End System Identifier. Overloading topology > onto it is part of why we are worried about scaling limits in routing > tables. > > Owen > > > --On April 25, 2006 10:56:49 AM -0700 Peter Sherbin > wrote: > > >> ... the PI/PA debate is or should be pointless. > > > > Perhaps a consesus definition of an IP address could help, e.g.: > > An IP address is a unique topological identifier of the interface where > > the number of bits in the address determines the version of IP. > > > > This would remove the ownership topic because no one owns the whole or a > > part of any particular version of the protocol. > > > > Peter > > > > > > --- bmanning at vacation.karoshi.com wrote: > > > >> On Mon, Apr 24, 2006 at 04:27:06PM -0400, Jason Schiller > >> (schiller at uu.net) wrote: > >> > Bill, > >> > > >> > Are you saying the right place to solve the private addressing issue > >> > is in the individual RIRs? > >> > >> perhaps i was unclear. the ULA proposal from the IETF > >> create property rights in IP address space, a concept that > >> to date, is antithical to the RIR premise that IP space > >> is roughly analogous to frequencies... e.g. can I OWN > >> the frequency band between 10.8GHz and 11.2Ghz and require > >> anyone who uses it to pay me royalties on a global basis? > >> > >> the IETF proposal allows entities to claim ownership, via > >> first come, first served, of IP space. There is some precident > >> at least in the US system of law, which argues against the > >> ability to own numbers. My fears may be unfounded in this > >> regard. > >> > >> but the ULA central proposal does create yet another registry, > >> the "central" thing that is supposed to track who is holding what. > >> And there is no plan to provide a viaable businsess model for such > >> a "central" holder. And there is no current way that "central" > >> can or would coordinate with the other RIRs. > >> > >> -MY- assertion is that there is or should be no distinction > >> on an address delegation... the PI/PA debate is or should be > >> pointless. You get a delegation or not. You can chose to make > >> subsiquent delegations from your delegated space or not. > >> And it is reasonable to place conditions on a delegation such that > >> it is recoverable... presuming the horse has not left the barn. > >> > >> that said, ARIN policy is created through the the open policy > >> process. if you -WANT- to add more policies, go for it. > >> I'd prefer to revamp most of the policies and come up wiht > >> a few core things and not build up a big policy analysis group. > >> > >> --bill > >> > >> > > >> > I just want to be clear on this point so I can determine the best > >> > place to focus my efforts. > >> > > >> > I thought what I heard at the last ARIN meeting was that the ARIN > >> > policy on should not supercede and RFC on unique local addressing. > >> > > >> > This is troubling as it is my understing of the history of > >> > draft-ietf-ipv6-ula-central-01.txt is that in got 7/8s finished and > >> > then it died at the ARIN stage, but one of the things holding up the > >> > ARIN policy 2006-2 was that it really should be pursued in the IETF > >> > first. > >> > > >> > Many people who previuosly worked on draft-ietf-ipv6-ula-central-01.txt > >> > are not intrested in reviving the draft if it is just going to die at > >> > ateh ARIN stage. I would hate to invest time on the ARIN policy if > >> > people are not likely to accept it without an RFC. > >> > > >> > So the question I have for you and everyone is where is the best place > >> > to pursue this? > >> > > >> > ___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 Sat, 22 Apr 2006 bmanning at vacation.karoshi.com wrote: > >> > > >> > > On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: > >> > > > Cons: > >> > > > > >> > > > 1) ARIN pretty vocally shot down the document a year or more ago, > >> > > > and the IETF basically decided "we don't need this so badly as to > >> > > > have a showdown with the ARIN community". Having said that, I > >> > > > (and others) still think the idea has some merit and would be > >> > > > willing to push on it on the IETF end, assuming we wouldn't get > >> > > > a repeat reaction at future meetings for our efforts... > >> > > > >> > > the reasons, imho, that ARIN gave this the thumbs down was A) that > >> > > it creates property rights, and B) has the IETF creating an other > >> > > address registry out of whole cloth - not following the defined > >> > > RIR creation > >> > > process. For me, the first is fundamentally fatal. > >> > > > >> > > > > >> > > > Note: AFAIK, no such reaction seemed to come out of APNIC or > >> > > > RIPE. > >> > > > > >> > > > I know that there is at least one person willing to resurrect the > >> > > > ula-central document, but I (personally) don't want to invest > >> > > > cycles in it if it's going to get a frosty reception in ARIN > >> > > > again. Been there, done that. > >> > > > > >> > > > Thomas > >> > > >> _______________________________________________ > >> PPML mailing list > >> PPML at arin.net > >> http://lists.arin.net/mailman/listinfo/ppml > >> > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > -- > If it wasn't crypto-signed, it probably didn't come from me. > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From Lee.Howard at stanleyassociates.com Tue Apr 25 16:31:40 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 25 Apr 2006 16:31:40 -0400 Subject: [ppml] Just say *NO* to PI space -- or howto make it less destructive Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB401E4DA16@CL-S-EX-1.stanleyassociates.com> I've made some changes to this message: I removed other mailing lists. I'm not a subscriber. I changed to plain text formatting. I tried to focus on ARIN public policy proposals. Matthew Petach wrote: > > dynamicity. Huston's study indicated that there are folks whose BGP > > announcements flap (due to TE) intentionally 1000's of times a day. > BGP flap dampening is already well understood for limiting the impact > of flapping routes on your CPU, if that's a concern; it has no bearing > on address allocation policy decisionmaking. Dampening works, for the value of "works" which equals "suppressing new (better?) information about the path to a network," which is often equal to "misrouting data because a new path was not calculated." If, following this proposed policy, aggressive dampening becomes commonly required by operators to maintain their networks, it might have a bearing on support for this policy. > pool. The policy cannot allow itself to be shaped by the least-capable > routers, or we'll be chaining ourselves to the past,unable to make adequate > forward progress so long as there's any network out there that's still running > old hardware that's unwilling to upgrade. > I agree we need to be reasonable--but please, let's not "dumb down" the > v6 internet just because some people aren't willing to step up to the plate and > upgrade their routers when needed. For values of "unwilling" approaching "unable." As the number of prefixes approaches infinity, and the beta cycle (or dynamism) approaches zero, the CPU required will approach infinity. Even if you decide to recalculate routes once a month, memory requirements increase, potentially beyond what current or foreseeable routers can handle. Yes, this is a reductio ad infinitum argument; the trouble is that there is not common agreement on what the break point is, or how fast it might approach. If it takes six months of testing to be confident in a new core router, and you replace 5% of your routers every week, and you ignore all other maintenance, you could replace your core in a year. Another year for distribution and edge. Any other kinds of devices take another year, for testing and rollout. That's assuming you employ as many engineers as needed, and ignore other work. I certainly don't mean you have to agree that these issues should be paramount in policy-making, but I think that before being ignored, it should be acknowledged that otherwise competent operators potentially have a serious problem. > Provider independence is here already, period. It's too late to try to put > the horse back in the barn I don't understand what you mean here. Do you mean "policy proposal 2005-1 is in last call and I believe it will be approved"? The last call part of the process exists for a reason; the AC will review comments about 2005-1 before deciding whether to promote the proposal. Or are you talking about other regions, which set their own policies? > Trying to stop provider independent addressing in IPv6 is simply another way > of saying 'IPv6 addressing is broken, let's just stick with IPv4 instead' -- because > that's what the practical outcome is. Are you asserting that IPv6 is, or is not, "broken"? Is a PI policy like 2005-1 intended to "fix" IPv6 or is it simply meeting the original requirements from the IETF? > Any addressing scheme that tries to > deny the need for provider independent addressing is less capable for > businesses than what they have today in the IPv4 world, and will therefore > not be used. Interesting assertion. In the context of 2005-1, which provides specific "bridles" to use your metaphor, are you suggesting it should move forward, or not? Whether it is too permissive or too restrictive is another interesting question, but doesn't sufficiently inform the process. > So. Given that PI allocations are going to happen in IPv6 just as they have in > IPv4, When you say, "just as they have in IPv4," what do you mean? Do you mean, "any applicant in the first ten years will get one with little justification, and anyone after that will have to provide documentation of their need"? 2005-1 isn't identical to IPv4, but uses IPv4 as its basis. > I *do* agree that stipulating that only the largest possible aggregate assigned > to a given AS *should be* announced by the AS is a reasonable addition to > the policy to help encourage aggregation, and prevent stupid routing mistakes In this context, do you oppose 2005-1 since it lacks such a recommendation? If this is an RFC2119 "should" then can the policy stand without it? > I don't see why the discussion is dragging out for so long. This isn't rocket > science. Let's just nail the policy down, and move on with more productive > work. Is that a statement for or against 2005-1? As to your statement about rocket science. . . developping consensus among people with opposite perspectives is distinctly difficult. I've never tried rocket science, but I know of some nuclear physicists who find consensus-building to be challenging. > Matt Lee From owen at delong.com Tue Apr 25 16:33:05 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Apr 2006 13:33:05 -0700 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <20060425192245.75649.qmail@web54702.mail.yahoo.com> References: <20060425192245.75649.qmail@web54702.mail.yahoo.com> Message-ID: Removing topology from the definition neither changes nor retains the current internet hierarchy. It simply leaves it out of the definition. It is conceivable that routing could be performed based on locators other than the IP address of the destination. For example, IDR could be conducted entirely based on ORIGIN AS and AS PATH information. The current (and at least some possible futures) can be addressed as follows: An IP address is an integer which identifies a particular system capable of initiating or accepting IP datagrams. Owen --On April 25, 2006 12:22:45 PM -0700 Peter Sherbin wrote: > Removing topology from the definition changes the current Internet > hierarchy. Then the immediate next step would be defining the > architecture where topology does not matter(?) > > Peter > > --- Owen DeLong wrote: > >> However, in the long run, tying IP Address to Topology as a definition >> would further cement what I believe is an error in the protocol design. >> The IP address should be strictly an End System Identifier. Overloading >> topology onto it is part of why we are worried about scaling limits in >> routing tables. >> >> Owen >> >> >> --On April 25, 2006 10:56:49 AM -0700 Peter Sherbin >> wrote: >> >> >> ... the PI/PA debate is or should be pointless. >> > >> > Perhaps a consesus definition of an IP address could help, e.g.: >> > An IP address is a unique topological identifier of the interface where >> > the number of bits in the address determines the version of IP. >> > >> > This would remove the ownership topic because no one owns the whole or >> > a part of any particular version of the protocol. >> > >> > Peter >> > >> > >> > --- bmanning at vacation.karoshi.com wrote: >> > >> >> On Mon, Apr 24, 2006 at 04:27:06PM -0400, Jason Schiller >> >> (schiller at uu.net) wrote: >> >> > Bill, >> >> > >> >> > Are you saying the right place to solve the private addressing issue >> >> > is in the individual RIRs? >> >> >> >> perhaps i was unclear. the ULA proposal from the IETF >> >> create property rights in IP address space, a concept that >> >> to date, is antithical to the RIR premise that IP space >> >> is roughly analogous to frequencies... e.g. can I OWN >> >> the frequency band between 10.8GHz and 11.2Ghz and require >> >> anyone who uses it to pay me royalties on a global basis? >> >> >> >> the IETF proposal allows entities to claim ownership, via >> >> first come, first served, of IP space. There is some precident >> >> at least in the US system of law, which argues against the >> >> ability to own numbers. My fears may be unfounded in this >> >> regard. >> >> >> >> but the ULA central proposal does create yet another registry, >> >> the "central" thing that is supposed to track who is holding what. >> >> And there is no plan to provide a viaable businsess model for such >> >> a "central" holder. And there is no current way that "central" >> >> can or would coordinate with the other RIRs. >> >> >> >> -MY- assertion is that there is or should be no distinction >> >> on an address delegation... the PI/PA debate is or should be >> >> pointless. You get a delegation or not. You can chose to make >> >> subsiquent delegations from your delegated space or not. >> >> And it is reasonable to place conditions on a delegation such that >> >> it is recoverable... presuming the horse has not left the barn. >> >> >> >> that said, ARIN policy is created through the the open policy >> >> process. if you -WANT- to add more policies, go for it. >> >> I'd prefer to revamp most of the policies and come up wiht >> >> a few core things and not build up a big policy analysis group. >> >> >> >> --bill >> >> >> >> > >> >> > I just want to be clear on this point so I can determine the best >> >> > place to focus my efforts. >> >> > >> >> > I thought what I heard at the last ARIN meeting was that the ARIN >> >> > policy on should not supercede and RFC on unique local addressing. >> >> > >> >> > This is troubling as it is my understing of the history of >> >> > draft-ietf-ipv6-ula-central-01.txt is that in got 7/8s finished and >> >> > then it died at the ARIN stage, but one of the things holding up >> >> > the ARIN policy 2006-2 was that it really should be pursued in the >> >> > IETF first. >> >> > >> >> > Many people who previuosly worked on >> >> > draft-ietf-ipv6-ula-central-01.txt are not intrested in reviving >> >> > the draft if it is just going to die at ateh ARIN stage. I would >> >> > hate to invest time on the ARIN policy if people are not likely to >> >> > accept it without an RFC. >> >> > >> >> > So the question I have for you and everyone is where is the best >> >> > place to pursue this? >> >> > >> >> > ___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 Sat, 22 Apr 2006 bmanning at vacation.karoshi.com wrote: >> >> > >> >> > > On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: >> >> > > > Cons: >> >> > > > >> >> > > > 1) ARIN pretty vocally shot down the document a year or more >> >> > > > ago, and the IETF basically decided "we don't need this so >> >> > > > badly as to have a showdown with the ARIN community". Having >> >> > > > said that, I (and others) still think the idea has some >> >> > > > merit and would be willing to push on it on the IETF end, >> >> > > > assuming we wouldn't get a repeat reaction at future >> >> > > > meetings for our efforts... >> >> > > >> >> > > the reasons, imho, that ARIN gave this the thumbs down was A) >> >> > > that it creates property rights, and B) has the IETF creating >> >> > > an other address registry out of whole cloth - not following the >> >> > > defined RIR creation >> >> > > process. For me, the first is fundamentally fatal. >> >> > > >> >> > > > >> >> > > > Note: AFAIK, no such reaction seemed to come out of APNIC or >> >> > > > RIPE. >> >> > > > >> >> > > > I know that there is at least one person willing to resurrect >> >> > > > the ula-central document, but I (personally) don't want to >> >> > > > invest cycles in it if it's going to get a frosty reception in >> >> > > > ARIN again. Been there, done that. >> >> > > > >> >> > > > Thomas >> >> > >> >> _______________________________________________ >> >> PPML mailing list >> >> PPML at arin.net >> >> http://lists.arin.net/mailman/listinfo/ppml >> >> >> > >> > >> > __________________________________________________ >> > Do You Yahoo!? >> > Tired of spam? Yahoo! Mail has the best spam protection around >> > http://mail.yahoo.com >> > _______________________________________________ >> > PPML mailing list >> > PPML at arin.net >> > http://lists.arin.net/mailman/listinfo/ppml >> >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From George.Kuzmowycz at aipso.com Tue Apr 25 16:39:04 2006 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Tue, 25 Apr 2006 16:39:04 -0400 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Message-ID: David Williamson wrote on 04/25/2006 9:42:40 AM: > On Tue, Apr 25, 2006 at 08:12:10AM +0000, bmanning at vacation.karoshi.com > wrote: >> On Mon, Apr 24, 2006 at 04:27:06PM -0400, Jason Schiller (schiller at uu.net) >> wrote: >> perhaps i was unclear. the ULA proposal from the IETF >> create property rights in IP address space, a concept that >> to date, is antithical to the RIR premise that IP space >> is roughly analogous to frequencies... e.g. can I OWN >> the frequency band between 10.8GHz and 11.2Ghz and require >> anyone who uses it to pay me royalties on a global basis? > > I haven't read the IETF proposal, but I'm hoping that we can simply > link this hypothetical internal infrastructure allocation to holding an > AS. In that way, there's no ownership created, since you certainly > don't own an AS number. The RIRs would still be the allocators of > space out of the global reserved block for this purpose: they simply > provide stewardship of the chunk associated with the ASNs allocated to > them. > > Sounds like I better go read the draft. I agree that ownership rights > would be a problem Why is the (potential) ownership of IP addresses a Bad Thing? From owen at delong.com Tue Apr 25 16:43:54 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Apr 2006 13:43:54 -0700 Subject: [ppml] Just say *NO* to PI space -- or howto make it less destructive In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401E4DA16@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB401E4DA16@CL-S-EX-1.stanleyassoc iates.com> Message-ID: <032E532330BCDD25A98048B9@odpwrbook.hq.netli.lan> >> I don't see why the discussion is dragging out for so long. This > isn't rocket >> science. Let's just nail the policy down, and move on with more > productive >> work. > > Is that a statement for or against 2005-1? > > As to your statement about rocket science. . . developping consensus > among > people with opposite perspectives is distinctly difficult. I've never > tried rocket science, but I know of some nuclear physicists who find > consensus-building to be challenging. As one of the authors who wrote 2005-1 and a Tripoli and NAR certified Level 2 rocketeer, I can tell you that rocket science is, for the most part, much simpler and easier than ARIN consensus building. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From narten at us.ibm.com Tue Apr 25 17:16:37 2006 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 25 Apr 2006 17:16:37 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: Message from "Tony Li" of "Tue, 25 Apr 2006 10:00:21 PDT." <008e01c66889$bcb318e0$b101a8c0@tropos.com> Message-ID: <200604252116.k3PLGb5D006787@cichlid.raleigh.ibm.com> "Tony Li" writes: > > What I see frustrating here is that everyone agrees we need > > some sort of "internet community agreement" that addresses V6 > > routing. I hear alot of people asking for this, including > > myself. Yet I dont hear any specific forum stepping forward > > to help facilitate this need. > What you're asking for is a "routing and addressing architecture". > Currently, it's really the purview of the IETF, except that they've > basically abdicated the role. This creates a vacuum, which, as you note > cries out to be filled. There are multiple ways to make progress here, > but my favorite is for ARIN to simply push the problem back to the IETF > and insist on a sensible and scalable solution. I think that what people want has a lot to do with operations and operational practices, an area the IETF struggles with at times. There is v6ops WG in the IETF: http://www.ietf.org/html.charters/v6ops-charter.html Reading the charter, my takes is that what I think I'm hearing people calling for (best practices on things like route filters, is deaggration allowed or not and under what conditions, etc., etc.) would be in-scope there. Maybe it's time to approach that group (and the ADs), see if there is a willingness to take on such work in the IETF. What they will want to see is a critical mass of folk agreeing on the work that needs to be done (i.e., what kind of document and what is in it) and assurance that there are enough volunteers to do the actual work. Even if the work is "officially" housed there, there is no reason why the work couldn't also be discussed in the various RIR and operations groups. I think the IETF would be as good a place as any to try and do this work. (And I'm willing to help make this happen if people think this is worth pursuing.) Thomas From marla_azinger at eli.net Tue Apr 25 17:41:59 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Tue, 25 Apr 2006 14:41:59 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A54B@wava00s2ke2k01.corp.pvt> Great! So we have at least a few of us interested enough to push this. However, my only concern with pushing through IETF is the time frame. Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Thomas Narten Sent: Tuesday, April 25, 2006 2:17 PM To: tony.li at tony.li Cc: ppml at arin.net Subject: Re: [ppml] "Recommended Practices" procedure "Tony Li" writes: > > What I see frustrating here is that everyone agrees we need > > some sort of "internet community agreement" that addresses V6 > > routing. I hear alot of people asking for this, including > > myself. Yet I dont hear any specific forum stepping forward > > to help facilitate this need. > What you're asking for is a "routing and addressing architecture". > Currently, it's really the purview of the IETF, except that they've > basically abdicated the role. This creates a vacuum, which, as you note > cries out to be filled. There are multiple ways to make progress here, > but my favorite is for ARIN to simply push the problem back to the IETF > and insist on a sensible and scalable solution. I think that what people want has a lot to do with operations and operational practices, an area the IETF struggles with at times. There is v6ops WG in the IETF: http://www.ietf.org/html.charters/v6ops-charter.html Reading the charter, my takes is that what I think I'm hearing people calling for (best practices on things like route filters, is deaggration allowed or not and under what conditions, etc., etc.) would be in-scope there. Maybe it's time to approach that group (and the ADs), see if there is a willingness to take on such work in the IETF. What they will want to see is a critical mass of folk agreeing on the work that needs to be done (i.e., what kind of document and what is in it) and assurance that there are enough volunteers to do the actual work. Even if the work is "officially" housed there, there is no reason why the work couldn't also be discussed in the various RIR and operations groups. I think the IETF would be as good a place as any to try and do this work. (And I'm willing to help make this happen if people think this is worth pursuing.) Thomas _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From marla_azinger at eli.net Tue Apr 25 17:47:33 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Tue, 25 Apr 2006 14:47:33 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A54C@wava00s2ke2k01.corp.pvt> Also, I feel as though ARIN/NANOG discussion and forum would lead to a more balanced internet community solution. Keeping a document that can reside in a specific "reachable" place would be nice. If it were to reside as a Best business Practice Document with ARIN/NANOG then I feel the ability to "change" it when needed would also be easier to accomplish. Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Thomas Narten Sent: Tuesday, April 25, 2006 2:17 PM To: tony.li at tony.li Cc: ppml at arin.net Subject: Re: [ppml] "Recommended Practices" procedure "Tony Li" writes: > > What I see frustrating here is that everyone agrees we need > > some sort of "internet community agreement" that addresses V6 > > routing. I hear alot of people asking for this, including > > myself. Yet I dont hear any specific forum stepping forward > > to help facilitate this need. > What you're asking for is a "routing and addressing architecture". > Currently, it's really the purview of the IETF, except that they've > basically abdicated the role. This creates a vacuum, which, as you note > cries out to be filled. There are multiple ways to make progress here, > but my favorite is for ARIN to simply push the problem back to the IETF > and insist on a sensible and scalable solution. I think that what people want has a lot to do with operations and operational practices, an area the IETF struggles with at times. There is v6ops WG in the IETF: http://www.ietf.org/html.charters/v6ops-charter.html Reading the charter, my takes is that what I think I'm hearing people calling for (best practices on things like route filters, is deaggration allowed or not and under what conditions, etc., etc.) would be in-scope there. Maybe it's time to approach that group (and the ADs), see if there is a willingness to take on such work in the IETF. What they will want to see is a critical mass of folk agreeing on the work that needs to be done (i.e., what kind of document and what is in it) and assurance that there are enough volunteers to do the actual work. Even if the work is "officially" housed there, there is no reason why the work couldn't also be discussed in the various RIR and operations groups. I think the IETF would be as good a place as any to try and do this work. (And I'm willing to help make this happen if people think this is worth pursuing.) Thomas _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From jason.schiller at mci.com Tue Apr 25 18:05:27 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Tue, 25 Apr 2006 18:05:27 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D20295A54C@wava00s2ke2k01.corp.pvt> Message-ID: I also think this effort is worth pursuing. The time frame of the IETF is certainly a factor. And the open process of ARIN and a single living policy document that is ammended and revised seems well suited to this task. I think it seems natural to group number policy and routing policy together as they are closely intertwined. Yet ARIN/NANOG are US centric. What forums would take on this role in other parts of the globe, and how would all of these get synthesized into a single global policy standard? The IETF is a global group. That may be both good and bad. Good that there is a single global standard, but bad if that standard under represents certain regions of the globe. I guess my biggest concern is that I'm not sure there is a critical mass of operators from each of the regions at the IETF. ___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, 25 Apr 2006, Azinger, Marla wrote: > Date: Tue, 25 Apr 2006 14:47:33 -0700 > From: "Azinger, Marla" > To: Thomas Narten , tony.li at tony.li > Cc: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > Also, I feel as though ARIN/NANOG discussion and forum would lead to a more balanced internet community solution. Keeping a document that can reside in a specific "reachable" place would be nice. If it were to reside as a Best business Practice Document with ARIN/NANOG then I feel the ability to "change" it when needed would also be easier to accomplish. > > Marla > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Thomas Narten > Sent: Tuesday, April 25, 2006 2:17 PM > To: tony.li at tony.li > Cc: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > > "Tony Li" writes: > > > > What I see frustrating here is that everyone agrees we need > > > some sort of "internet community agreement" that addresses V6 > > > routing. I hear alot of people asking for this, including > > > myself. Yet I dont hear any specific forum stepping forward > > > to help facilitate this need. > > > What you're asking for is a "routing and addressing architecture". > > Currently, it's really the purview of the IETF, except that they've > > basically abdicated the role. This creates a vacuum, which, as you note > > cries out to be filled. There are multiple ways to make progress here, > > but my favorite is for ARIN to simply push the problem back to the IETF > > and insist on a sensible and scalable solution. > > I think that what people want has a lot to do with operations and > operational practices, an area the IETF struggles with at times. There > is v6ops WG in the IETF: > > http://www.ietf.org/html.charters/v6ops-charter.html > > Reading the charter, my takes is that what I think I'm hearing people > calling for (best practices on things like route filters, is > deaggration allowed or not and under what conditions, etc., etc.) > would be in-scope there. > > Maybe it's time to approach that group (and the ADs), see if there is > a willingness to take on such work in the IETF. What they will want to > see is a critical mass of folk agreeing on the work that needs to be > done (i.e., what kind of document and what is in it) and assurance > that there are enough volunteers to do the actual work. Even if the > work is "officially" housed there, there is no reason why the work > couldn't also be discussed in the various RIR and operations > groups. > > I think the IETF would be as good a place as any to try and do this > work. (And I'm willing to help make this happen if people think this > is worth pursuing.) > > Thomas > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From tme at multicasttech.com Tue Apr 25 18:08:43 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 25 Apr 2006 18:08:43 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D20295A54C@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D20295A54C@wava00s2ke2k01.corp.pvt> Message-ID: <7D6A02C9-1D0E-4D13-9835-6FA22CC69029@multicasttech.com> This issue had a big discussion about this at the RIPE-52 meeting now on-going in Istanbul, and I believe that a resolution similar to 2005-1 is likely to result from it. Are you going to ignore them and the other communities. I would suggest a BOF at the Montreal IETF. Here are the parameters for doing this : ----- -- Cut-off date for requesting a session: Monday, June 5 at 17:00 ET (21:00 UTC/GMT). -- Preliminary agenda published for comment: Friday, June 9 by midnight ET. -- Cut-off date for requests to reschedule a session: Wednesday, June 14 at 09:00 ET (13:00 UTC/GMT). -- Final schedule published: Monday, June 19 before midnight ET. Submitting Requests for Working Group and BOF Sessions Please submit requests to schedule your Working Group sessions using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information that the Secretariat requires to schedule your sessions. ----- Regards Marshall On Apr 25, 2006, at 5:47 PM, Azinger, Marla wrote: > Also, I feel as though ARIN/NANOG discussion and forum would lead > to a more balanced internet community solution. Keeping a document > that can reside in a specific "reachable" place would be nice. If > it were to reside as a Best business Practice Document with ARIN/ > NANOG then I feel the ability to "change" it when needed would also > be easier to accomplish. > > Marla > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Thomas Narten > Sent: Tuesday, April 25, 2006 2:17 PM > To: tony.li at tony.li > Cc: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > > "Tony Li" writes: > >>> What I see frustrating here is that everyone agrees we need >>> some sort of "internet community agreement" that addresses V6 >>> routing. I hear alot of people asking for this, including >>> myself. Yet I dont hear any specific forum stepping forward >>> to help facilitate this need. > >> What you're asking for is a "routing and addressing architecture". >> Currently, it's really the purview of the IETF, except that they've >> basically abdicated the role. This creates a vacuum, which, as >> you note >> cries out to be filled. There are multiple ways to make progress >> here, >> but my favorite is for ARIN to simply push the problem back to the >> IETF >> and insist on a sensible and scalable solution. > > I think that what people want has a lot to do with operations and > operational practices, an area the IETF struggles with at times. There > is v6ops WG in the IETF: > > http://www.ietf.org/html.charters/v6ops-charter.html > > Reading the charter, my takes is that what I think I'm hearing people > calling for (best practices on things like route filters, is > deaggration allowed or not and under what conditions, etc., etc.) > would be in-scope there. > > Maybe it's time to approach that group (and the ADs), see if there is > a willingness to take on such work in the IETF. What they will want to > see is a critical mass of folk agreeing on the work that needs to be > done (i.e., what kind of document and what is in it) and assurance > that there are enough volunteers to do the actual work. Even if the > work is "officially" housed there, there is no reason why the work > couldn't also be discussed in the various RIR and operations > groups. > > I think the IETF would be as good a place as any to try and do this > work. (And I'm willing to help make this happen if people think this > is worth pursuing.) > > Thomas > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From jason.schiller at mci.com Tue Apr 25 18:13:19 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Tue, 25 Apr 2006 18:13:19 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <7D6A02C9-1D0E-4D13-9835-6FA22CC69029@multicasttech.com> Message-ID: Not that I dis-agree, but why not a BOF at the next NANOG? ___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, 25 Apr 2006, Marshall Eubanks wrote: > Date: Tue, 25 Apr 2006 18:08:43 -0400 > From: Marshall Eubanks > To: "Azinger, Marla" > Cc: Thomas Narten , ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > This issue had a big discussion about this at the RIPE-52 meeting now > on-going in Istanbul, and I believe > that a resolution similar to 2005-1 is likely to result from it. Are > you going to ignore them and the other communities. > > I would suggest a BOF at the Montreal IETF. Here are the parameters > for doing this : > > ----- > -- Cut-off date for requesting a session: Monday, June 5 at 17:00 ET > (21:00 > UTC/GMT). > -- Preliminary agenda published for comment: Friday, June 9 by > midnight ET. > -- Cut-off date for requests to reschedule a session: Wednesday, June > 14 at > 09:00 ET (13:00 UTC/GMT). > -- Final schedule published: Monday, June 19 before midnight ET. > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using > the "IETF > Meeting Session Request Tool," a Web-based tool for submitting all of > the > information that the Secretariat requires to schedule your sessions. > ----- > > Regards > Marshall > > On Apr 25, 2006, at 5:47 PM, Azinger, Marla wrote: > > > Also, I feel as though ARIN/NANOG discussion and forum would lead > > to a more balanced internet community solution. Keeping a document > > that can reside in a specific "reachable" place would be nice. If > > it were to reside as a Best business Practice Document with ARIN/ > > NANOG then I feel the ability to "change" it when needed would also > > be easier to accomplish. > > > > Marla > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > > Thomas Narten > > Sent: Tuesday, April 25, 2006 2:17 PM > > To: tony.li at tony.li > > Cc: ppml at arin.net > > Subject: Re: [ppml] "Recommended Practices" procedure > > > > > > "Tony Li" writes: > > > >>> What I see frustrating here is that everyone agrees we need > >>> some sort of "internet community agreement" that addresses V6 > >>> routing. I hear alot of people asking for this, including > >>> myself. Yet I dont hear any specific forum stepping forward > >>> to help facilitate this need. > > > >> What you're asking for is a "routing and addressing architecture". > >> Currently, it's really the purview of the IETF, except that they've > >> basically abdicated the role. This creates a vacuum, which, as > >> you note > >> cries out to be filled. There are multiple ways to make progress > >> here, > >> but my favorite is for ARIN to simply push the problem back to the > >> IETF > >> and insist on a sensible and scalable solution. > > > > I think that what people want has a lot to do with operations and > > operational practices, an area the IETF struggles with at times. There > > is v6ops WG in the IETF: > > > > http://www.ietf.org/html.charters/v6ops-charter.html > > > > Reading the charter, my takes is that what I think I'm hearing people > > calling for (best practices on things like route filters, is > > deaggration allowed or not and under what conditions, etc., etc.) > > would be in-scope there. > > > > Maybe it's time to approach that group (and the ADs), see if there is > > a willingness to take on such work in the IETF. What they will want to > > see is a critical mass of folk agreeing on the work that needs to be > > done (i.e., what kind of document and what is in it) and assurance > > that there are enough volunteers to do the actual work. Even if the > > work is "officially" housed there, there is no reason why the work > > couldn't also be discussed in the various RIR and operations > > groups. > > > > I think the IETF would be as good a place as any to try and do this > > work. (And I'm willing to help make this happen if people think this > > is worth pursuing.) > > > > Thomas > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From tme at multicasttech.com Tue Apr 25 18:30:48 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 25 Apr 2006 18:30:48 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: <8D20EB19-AEC0-4AFA-93AC-53574FAC18D2@multicasttech.com> Well, I am not going to say that I disagree about that either, but it's pretty clear to me that there are interested people here who do not generally come to NANOGs or ARIN meetings. Of course, many of them don't come to IETF's either... Marshall On Apr 25, 2006, at 6:13 PM, Jason Schiller (schiller at uu.net) wrote: > Not that I dis-agree, but why not a BOF at the next NANOG? > > ___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, 25 Apr 2006, Marshall Eubanks wrote: > >> Date: Tue, 25 Apr 2006 18:08:43 -0400 >> From: Marshall Eubanks >> To: "Azinger, Marla" >> Cc: Thomas Narten , ppml at arin.net >> Subject: Re: [ppml] "Recommended Practices" procedure >> >> This issue had a big discussion about this at the RIPE-52 meeting now >> on-going in Istanbul, and I believe >> that a resolution similar to 2005-1 is likely to result from it. Are >> you going to ignore them and the other communities. >> >> I would suggest a BOF at the Montreal IETF. Here are the parameters >> for doing this : >> >> ----- >> -- Cut-off date for requesting a session: Monday, June 5 at 17:00 >> ET >> (21:00 >> UTC/GMT). >> -- Preliminary agenda published for comment: Friday, June 9 by >> midnight ET. >> -- Cut-off date for requests to reschedule a session: Wednesday, >> June >> 14 at >> 09:00 ET (13:00 UTC/GMT). >> -- Final schedule published: Monday, June 19 before midnight ET. >> >> Submitting Requests for Working Group and BOF Sessions >> >> Please submit requests to schedule your Working Group sessions using >> the "IETF >> Meeting Session Request Tool," a Web-based tool for submitting all of >> the >> information that the Secretariat requires to schedule your sessions. >> ----- >> >> Regards >> Marshall >> >> On Apr 25, 2006, at 5:47 PM, Azinger, Marla wrote: >> >>> Also, I feel as though ARIN/NANOG discussion and forum would lead >>> to a more balanced internet community solution. Keeping a document >>> that can reside in a specific "reachable" place would be nice. If >>> it were to reside as a Best business Practice Document with ARIN/ >>> NANOG then I feel the ability to "change" it when needed would also >>> be easier to accomplish. >>> >>> Marla >>> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >>> Behalf Of >>> Thomas Narten >>> Sent: Tuesday, April 25, 2006 2:17 PM >>> To: tony.li at tony.li >>> Cc: ppml at arin.net >>> Subject: Re: [ppml] "Recommended Practices" procedure >>> >>> >>> "Tony Li" writes: >>> >>>>> What I see frustrating here is that everyone agrees we need >>>>> some sort of "internet community agreement" that addresses V6 >>>>> routing. I hear alot of people asking for this, including >>>>> myself. Yet I dont hear any specific forum stepping forward >>>>> to help facilitate this need. >>> >>>> What you're asking for is a "routing and addressing architecture". >>>> Currently, it's really the purview of the IETF, except that they've >>>> basically abdicated the role. This creates a vacuum, which, as >>>> you note >>>> cries out to be filled. There are multiple ways to make progress >>>> here, >>>> but my favorite is for ARIN to simply push the problem back to the >>>> IETF >>>> and insist on a sensible and scalable solution. >>> >>> I think that what people want has a lot to do with operations and >>> operational practices, an area the IETF struggles with at times. >>> There >>> is v6ops WG in the IETF: >>> >>> http://www.ietf.org/html.charters/v6ops-charter.html >>> >>> Reading the charter, my takes is that what I think I'm hearing >>> people >>> calling for (best practices on things like route filters, is >>> deaggration allowed or not and under what conditions, etc., etc.) >>> would be in-scope there. >>> >>> Maybe it's time to approach that group (and the ADs), see if >>> there is >>> a willingness to take on such work in the IETF. What they will >>> want to >>> see is a critical mass of folk agreeing on the work that needs to be >>> done (i.e., what kind of document and what is in it) and assurance >>> that there are enough volunteers to do the actual work. Even if the >>> work is "officially" housed there, there is no reason why the work >>> couldn't also be discussed in the various RIR and operations >>> groups. >>> >>> I think the IETF would be as good a place as any to try and do this >>> work. (And I'm willing to help make this happen if people think >>> this >>> is worth pursuing.) >>> >>> Thomas >>> >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > From mpetach at netflight.com Tue Apr 25 21:01:04 2006 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 25 Apr 2006 18:01:04 -0700 Subject: [ppml] Just say *NO* to PI space -- or howto make it less destructive In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401E4DA16@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB401E4DA16@CL-S-EX-1.stanleyassociates.com> Message-ID: <63ac96a50604251801j4a510f37wd2a311c6f987df25@mail.gmail.com> On 4/25/06, Howard, W. Lee wrote: > > I've made some changes to this message: > I removed other mailing lists. I'm not a subscriber. > I changed to plain text formatting. > I tried to focus on ARIN public policy proposals. > > Matthew Petach wrote: > > > dynamicity. Huston's study indicated that there are folks whose BGP > > > announcements flap (due to TE) intentionally 1000's of times a day. > > BGP flap dampening is already well understood for limiting the impact > > of flapping routes on your CPU, if that's a concern; it has no bearing > > on address allocation policy decisionmaking. > > Dampening works, for the value of "works" which equals "suppressing new > (better?) information about the path to a network," which is often equal > to "misrouting data because a new path was not calculated." If, > following > this proposed policy, aggressive dampening becomes commonly required by > operators to maintain their networks, it might have a bearing on support > for this policy. Concern was raised about end networks changing routing state too quickly for modern CPUs to handle; the way we handle that today is to dampen successive transitions once they reach a certain threshold level. I see no reason why the current mechanism in use today in the IPv4 world should not work just as well on the IPv6 network. > pool. The policy cannot allow itself to be shaped by the > least-capable > > routers, or we'll be chaining ourselves to the past,unable to make > adequate > > forward progress so long as there's any network out there that's still > running > > old hardware that's unwilling to upgrade. > > I agree we need to be reasonable--but please, let's not "dumb down" > the > > v6 internet just because some people aren't willing to step up to the > plate and > > upgrade their routers when needed. > > For values of "unwilling" approaching "unable." As the number of > prefixes > approaches infinity, and the beta cycle (or dynamism) approaches zero, > the > CPU required will approach infinity. Even if you decide to recalculate > routes once a month, memory requirements increase, potentially beyond > what > current or foreseeable routers can handle. Yes, this is a reductio ad > infinitum argument; the trouble is that there is not common agreement on > what the break point is, or how fast it might approach. > > If it takes six months of testing to be confident in a new core router, > and you replace 5% of your routers every week, and you ignore all other > maintenance, you could replace your core in a year. Another year for > distribution and edge. Any other kinds of devices take another year, > for testing and rollout. That's assuming you employ as many engineers > as needed, and ignore other work. > > I certainly don't mean you have to agree that these issues should be > paramount in policy-making, but I think that before being ignored, it > should be acknowledged that otherwise competent operators potentially > have a serious problem. The point I was making is that if we limit IP allocation policies based on hardware upgrade cycles, we shackle ourselves to the ISP that decides that they should be able to run just fine with their IGS or AGS+, and therefore no additional prefixes can be allocated because they're unwilling _or_ unable to upgrade. If we start putting limits on what can be assigned due to concerns about what some providers may be unwilling to upgrade in their core, are we also going to entertain proposals to limit IPv4 allocations so that those selfsame providers won't have to upgrade their IPv4 routers either? Let's be realistic. We don't have any limits on how much IPv4 deaggregation we'll support, we just trust the routers to scale up to support the growth--why are we attempting to treat IPv6 differently? Do we not expect IPv6 to take over for IPv4 in the forseeable future? > Provider independence is here already, period. It's too late to try > to put > > the horse back in the barn > > I don't understand what you mean here. Do you mean "policy proposal > 2005-1 > is in last call and I believe it will be approved"? The last call part > of > the process exists for a reason; the AC will review comments about > 2005-1 > before deciding whether to promote the proposal. Or are you talking > about other regions, which set their own policies? I mean 'In the IPv4 internet of today, multihoming is a fact of life, and is expected by businesses. If IPv6 is ever intended to be more than an academic mastubatory exercise, the policies associated with IPv6 allocations will need to support a similar or better level of provider independence for businesses as the existing IPv4 allocation policies.' To that end, yes, I support 2005-1. I anticipate it being approved. If it is not approved, and none of the other possible proposals for IPv6 multihoming for enterprise networks are approved, I see no reason to think that IPv6 will ever be used as anything other than an experimental protocol utilized by small groups of researchers. > Trying to stop provider independent addressing in IPv6 is simply > another way > > of saying 'IPv6 addressing is broken, let's just stick with IPv4 > instead' -- because > > that's what the practical outcome is. > > Are you asserting that IPv6 is, or is not, "broken"? Is a PI policy > like 2005-1 intended to "fix" IPv6 or is it simply meeting the original > requirements from the IETF? IPv6 without provider independent allocations is broken, and will never be widely adopted. 2005-1 is one possible suggestion on how to fix it. I support 2005-1 as a well thought out means to fix an otherwise broken protocol. > Any addressing scheme that tries to > > deny the need for provider independent addressing is less capable for > > businesses than what they have today in the IPv4 world, and will > therefore > > not be used. > > Interesting assertion. In the context of 2005-1, which provides > specific > "bridles" to use your metaphor, are you suggesting it should move > forward, > or not? Whether it is too permissive or too restrictive is another > interesting question, but doesn't sufficiently inform the process. Yes. I have previously stated on other threads, and will continue to state that 2005-1 should move forward, or if there is sufficient concern about wording, that one of its progeny or siblings should move forward; but without some form of provider independent allocation scheme for non-ISP multihomed networks included in the IPv6 allocation policy, IPv4 will continue to be the dominant network platform, and no level of critical mass will be reached to support widespread IPv6 deployment. > So. Given that PI allocations are going to happen in IPv6 just as > they have in > > IPv4, > > When you say, "just as they have in IPv4," what do you mean? Do you > mean, > "any applicant in the first ten years will get one with little > justification, > and anyone after that will have to provide documentation of their need"? > 2005-1 isn't identical to IPv4, but uses IPv4 as its basis. I think 2005-1 is sufficiently similar to the current IPv4 allocation system for my language to be applicable. > I *do* agree that stipulating that only the largest possible aggregate > assigned > > to a given AS *should be* announced by the AS is a reasonable addition > to > > the policy to help encourage aggregation, and prevent stupid routing > mistakes > > In this context, do you oppose 2005-1 since it lacks such a > recommendation? > If this is an RFC2119 "should" then can the policy stand without it? No, I don't oppose 2005-1 as it stands. I'm tossing out an idea for an addition that might help those who live in fear of route table expansion feel more comfortable with it. Strictly speaking, though, even with no changes, no amendments, no adjustments, I think 2005-1 is more than adequate, and can be approved as it stands without fear of the internet melting down due to its adoption. > I don't see why the discussion is dragging out for so long. This > isn't rocket > > science. Let's just nail the policy down, and move on with more > productive > > work. > > Is that a statement for or against 2005-1? Yes. I am hoping to see IPv6 become something other than a theoretical protocol developed as an amusing experiment; therefore, I support 2005-1. As to your statement about rocket science. . . developping consensus > among > people with opposite perspectives is distinctly difficult. I've never > tried rocket science, but I know of some nuclear physicists who find > consensus-building to be challenging. That's nice. If we don't come to consensus and move forward, this rocket is never going to lift off. And if IPv6 doesn't take off, then we'll see some *real* challenges when IPv4 space starts getting scarce, and the black market for v4 space starts to solidify. You're worried about routing table growth in IPv6? Imagine what it'll be like when v4 space runs out in 5-8 years and suddenly those nice class A aggregates are being sliced and diced into /22 sized chunks for everyone screaming for provider independent, routable space. Suddenly, supporting PI space in IPv6 won't seem that bad. The same routing table slots are going to get used, period; all we're discussing here is whether we set up the policy such that they can be used for IPv6 routes, or if we force them to be used for IPv4 prefixes. I'm supporting 2005-1 because I'd prefer to see those prefixes handled on the IPv6 internet. It sounds like you'd prefer to say 'no' to IPv6 PI space, and instead have your routing slots consumed by IPv4 prefixes instead, and that's certainly your choice. I'm just trying to point out why I think it's a more short-sighted choice that will end up locking us more tightly into the IPv4 world, and why I favour the other choice, which is to support 2005-1 or one of its ilk, and help bring the IPv6 internet into the current millenium. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From pesherb at yahoo.com Tue Apr 25 21:06:28 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Tue, 25 Apr 2006 18:06:28 -0700 (PDT) Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal In-Reply-To: Message-ID: <20060426010628.78504.qmail@web54710.mail.yahoo.com> > Why is the (potential) ownership of IP addresses a Bad Thing? It is practicality rather than good vs. evil. Ownership implies control. If owner decides using 96 instead of 128-bits it impedes the system. Peter --- George Kuzmowycz wrote: > David Williamson wrote on 04/25/2006 9:42:40 AM: > > On Tue, Apr 25, 2006 at 08:12:10AM +0000, > bmanning at vacation.karoshi.com > > wrote: > >> On Mon, Apr 24, 2006 at 04:27:06PM -0400, Jason Schiller > (schiller at uu.net) > >> wrote: > >> perhaps i was unclear. the ULA proposal from the IETF > >> create property rights in IP address space, a concept that > >> to date, is antithical to the RIR premise that IP space > >> is roughly analogous to frequencies... e.g. can I OWN > >> the frequency band between 10.8GHz and 11.2Ghz and require > >> anyone who uses it to pay me royalties on a global basis? > > > > I haven't read the IETF proposal, but I'm hoping that we can simply > > link this hypothetical internal infrastructure allocation to holding > an > > AS. In that way, there's no ownership created, since you certainly > > don't own an AS number. The RIRs would still be the allocators of > > space out of the global reserved block for this purpose: they > simply > > provide stewardship of the chunk associated with the ASNs allocated > to > > them. > > > > Sounds like I better go read the draft. I agree that ownership > rights > > would be a problem > > Why is the (potential) ownership of IP addresses a Bad Thing? > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jason.schiller at mci.com Tue Apr 25 21:21:52 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Tue, 25 Apr 2006 21:21:52 -0400 (EDT) Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: <20060425081210.GH1014@vacation.karoshi.com> Message-ID: Thanks Bill, I got it this time. ___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, 25 Apr 2006 bmanning at vacation.karoshi.com wrote: > Date: Tue, 25 Apr 2006 08:12:10 +0000 > From: bmanning at vacation.karoshi.com > To: "Jason Schiller (schiller at uu.net)" > Cc: bmanning at vacation.karoshi.com, Thomas Narten , > ppml at arin.net > Subject: Re: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal > 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] > > On Mon, Apr 24, 2006 at 04:27:06PM -0400, Jason Schiller (schiller at uu.net) wrote: > > Bill, > > > > Are you saying the right place to solve the private addressing issue is in > > the individual RIRs? > > perhaps i was unclear. the ULA proposal from the IETF > create property rights in IP address space, a concept that > to date, is antithical to the RIR premise that IP space > is roughly analogous to frequencies... e.g. can I OWN > the frequency band between 10.8GHz and 11.2Ghz and require > anyone who uses it to pay me royalties on a global basis? > > the IETF proposal allows entities to claim ownership, via > first come, first served, of IP space. There is some precident > at least in the US system of law, which argues against the > ability to own numbers. My fears may be unfounded in this > regard. > > but the ULA central proposal does create yet another registry, > the "central" thing that is supposed to track who is holding what. > And there is no plan to provide a viaable businsess model for such > a "central" holder. And there is no current way that "central" > can or would coordinate with the other RIRs. > > -MY- assertion is that there is or should be no distinction > on an address delegation... the PI/PA debate is or should be > pointless. You get a delegation or not. You can chose to make > subsiquent delegations from your delegated space or not. > And it is reasonable to place conditions on a delegation such that > it is recoverable... presuming the horse has not left the barn. > > that said, ARIN policy is created through the the open policy > process. if you -WANT- to add more policies, go for it. > I'd prefer to revamp most of the policies and come up wiht > a few core things and not build up a big policy analysis group. > > --bill > > > > > I just want to be clear on this point so I can determine the best place to > > focus my efforts. > > > > I thought what I heard at the last ARIN meeting was that the ARIN policy > > on should not supercede and RFC on unique local addressing. > > > > This is troubling as it is my understing of the history of > > draft-ietf-ipv6-ula-central-01.txt is that in got 7/8s finished and then > > it died at the ARIN stage, but one of the things holding up the ARIN > > policy 2006-2 was that it really should be pursued in the IETF first. > > > > Many people who previuosly worked on draft-ietf-ipv6-ula-central-01.txt > > are not intrested in reviving the draft if it is just going to die at ateh > > ARIN stage. I would hate to invest time on the ARIN policy if people are > > not likely to accept it without an RFC. > > > > So the question I have for you and everyone is where is the best place to > > pursue this? > > > > ___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 Sat, 22 Apr 2006 bmanning at vacation.karoshi.com wrote: > > > > > On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote: > > > > Cons: > > > > > > > > 1) ARIN pretty vocally shot down the document a year or more ago, and > > > > the IETF basically decided "we don't need this so badly as to have > > > > a showdown with the ARIN community". Having said that, I (and > > > > others) still think the idea has some merit and would be willing to > > > > push on it on the IETF end, assuming we wouldn't get a repeat > > > > reaction at future meetings for our efforts... > > > > > > the reasons, imho, that ARIN gave this the thumbs down was A) that > > > it creates property rights, and B) has the IETF creating an other > > > address registry out of whole cloth - not following the defined > > > RIR creation > > > process. For me, the first is fundamentally fatal. > > > > > > > > > > > Note: AFAIK, no such reaction seemed to come out of APNIC or RIPE. > > > > > > > > I know that there is at least one person willing to resurrect the > > > > ula-central document, but I (personally) don't want to invest cycles > > > > in it if it's going to get a frosty reception in ARIN again. Been > > > > there, done that. > > > > > > > > Thomas > > > From randy at psg.com Wed Apr 26 02:11:13 2006 From: randy at psg.com (Randy Bush) Date: Wed, 26 Apr 2006 09:11:13 +0300 Subject: [ppml] Just say *NO* to PI space -- or howto make it less destructive References: <369EB04A0951824ABE7D8BAC67AF9BB401E4DA16@CL-S-EX-1.stanleyassociates.com> Message-ID: <17487.3841.307989.817974@roam.psg.com> >> BGP flap dampening is already well understood for limiting the impact >> of flapping routes on your CPU, if that's a concern; it has no bearing >> on address allocation policy decisionmaking. > > Dampening works, for the value of "works" which equals "suppressing new > (better?) information about the path to a network," which is often equal > to "misrouting data because a new path was not calculated." If, following > this proposed policy, aggressive dampening becomes commonly required by > operators to maintain their networks, it might have a bearing on support > for this policy. the current ripe damping recommendations originated in ripe. this week, ripe will consider a proposal to recommend that flap damping be un-recommended. randy From arin at sprint.net Wed Apr 26 02:15:53 2006 From: arin at sprint.net (Arin Archive) Date: Wed, 26 Apr 2006 02:15:53 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Message-ID: I am against this policy. It appears that most people at the last want to make a policy for policy's sake. There are many other things that haven't been looked at in addition to just IPv4 and IPv6 tables. I haven't heard or seen any studies of the impact that VPNs have in addtion and even get more nervious when discussions on PEv6 are brought up. As others have mentioned, historically temporary solutions aren't. I believe that we are making the same mistakes as we did when v4 was first rolled out with a /48 out of a reserved /44 per PI request. How large is this PI swamp that is being proposed? If 2005-1 is repealed, how will the space be returned without litigation? Odds are that it won't and we'll be forced with it with no recourse. Aaron Dudek From bmanning at vacation.karoshi.com Wed Apr 26 02:50:24 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 26 Apr 2006 06:50:24 +0000 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D0A@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D0A@wava00s2ke2k01.corp.pvt> Message-ID: <20060426065024.GF8687@vacation.karoshi.com.> On Tue, Apr 25, 2006 at 09:22:40AM -0700, Azinger, Marla wrote: > What I see frustrating here is that everyone agrees we need some sort of "internet community agreement" that addresses V6 routing. I hear alot of people asking for this, including myself. Yet I dont hear any specific forum stepping forward to help facilitate this need. > > Saying Jason is passing the buck is really not true. I see him as one of the people yelling outloud "hey I'm here to help, but a need a forum to facilitate." perhaps i am getting old and mis-understanding/mis-remembering previous discussions, but i do remember some discussion about collusion and anti-trust issues if ARIN was to specify/dictate what could or could not be routed. To reiterate, i do not think arin is the right plce for this ... --bill > > I ask myself "why does it appear that all known forums" are unwilling to touch this issue? I keep hearing "its not our charter". When I hear this "reason" I wonder again, do these charters exist as a hard bound document and if so, maybe it should be re-written. Or is there a "stewardship and spirit of the charter" that exists that we just need to acknowledge? see above. :) --bill From pekkas at netcore.fi Wed Apr 26 04:36:46 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 26 Apr 2006 11:36:46 +0300 (EEST) Subject: [ppml] Just say *NO* to PI space -- or howto make it less destructive In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401E4DA16@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB401E4DA16@CL-S-EX-1.stanleyassociates.com> Message-ID: On Tue, 25 Apr 2006, Howard, W. Lee wrote: > Matthew Petach wrote: >>> dynamicity. Huston's study indicated that there are folks whose BGP >>> announcements flap (due to TE) intentionally 1000's of times a day. >> BGP flap dampening is already well understood for limiting the impact >> of flapping routes on your CPU, if that's a concern; it has no bearing >> on address allocation policy decisionmaking. > > Dampening works, for the value of "works" which equals "suppressing > new (better?) information about the path to a network," which is > often equal to "misrouting data because a new path was not > calculated." If, following this proposed policy, aggressive > dampening becomes commonly required by operators to maintain their > networks, it might have a bearing on support for this policy. The effects of dampening depend a lot on where it's applied. Towards a customer end-site? In outgoing advertiement to your peers and upstreams for your own customers? By transit operators? By all the ASs for their incoming Internet/peering feeds? IMHO, flap damping closest to the source is the best approach because a multihomed site wouldn't lose connectivity, but unfortunately that isn't applied that often... or Geoff wouldn't have observed the advertisement flapping problems.. -- 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 Wed Apr 26 04:56:46 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 26 Apr 2006 09:56:46 +0100 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D0A@wava00s2ke2k01.corp.pvt> Message-ID: > What I see frustrating here is that everyone agrees we need some > sort of "internet community agreement" that addresses V6 routing. I > hear alot of people asking for this, including myself. Yet I dont > hear any specific forum stepping forward to help facilitate this need. Forums don't step forward, people do. Are you a person? As I said a few days ago: On the other hand, ARIN policy cannot restrict what two peers do between themselves. At this point in time, the global routing table is merely a convenient phrase used in routing discussions. There really is no such thing. Nobody manages the global routing table. There are no explicit agreements on what can or cannot be announced into the global routing table. And so on. If that were to change then your issues would be perfectly within scope. However, this would require the ARIN Board of Trustees to agree to undertake this activity. Interestingly enough, this does seem to be within ARIN's scope if you read items 2, 3, 4 and 6 of the purposes in the ARIN Articles of Incorporation. Assuming that there was to be an RIR function which produced guidelines for management of the global routing table, how would it operate and how would it ensure industry-wide consensus on those rules? I'm waiting to hear your answer for that last question. > I ask myself "why does it appear that all known forums" are > unwilling to touch this issue? I keep hearing "its not our > charter". When I hear this "reason" I wonder again, do these > charters exist as a hard bound document and if so, maybe it should > be re-written. When I heard that statement, I didn't wonder. Instead I looked up ARIN's charter, read it, and discovered that facilitating the development of global routing policy is squarely within ARIN's scope. > I also keep hearing "work the issue out between you and the other > providers". I agree, great idea, but we need a forum of > facilitation to do this. Here it is. This mailing list is a public forum. Instead of complaining, let's hear some substantive proposals. Remember, job one is how to get ISPs involved and how to develop consensus. Does it have to be done globally or is it feasible to have 5 different continental routing policies? > So what then? Do we create yet another Task Force? Or just keep > pointing our fingers in a circle from Forum to Forum? The journey of a thousand miles begins with one step. --Michael Dillon From sleibrand at internap.com Wed Apr 26 08:38:01 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 26 Apr 2006 08:38:01 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: References: Message-ID: On 04/26/06 at 2:15am -0400, Aaron Dudek wrote: > I am against this policy. Fair enough... > It appears that most people at the last want to make a policy for policy's > sake. I disagree. I think most people are in favor of 2005-1 because they recognize that this PI policy is better than no PI policy. > There are many other things that haven't been looked at in addition > to just IPv4 and IPv6 tables. I haven't heard or seen any studies of the > impact that VPNs have in addition and even get more nervous when > discussions on PEv6 are brought up. I'm not sure what special impact PI space would have on VPNs or PEv6. Can you elaborate? In particular, do you have any idea how many PI routes it would take to start breaking either technology (given current hardware)? > As others have mentioned, historically temporary solutions aren't. I > believe that we are making the same mistakes as we did when v4 was first > rolled out with a /48 out of a reserved /44 per PI request. How large is > this PI swamp that is being proposed? The number of PI allocations will be small, at least at first. The number of entities that have gotten IPv4 PI is small (less than 10,000 IIRC), and you have to qualify for IPv4 PI to get IPv6 PI under 2005-1. Hardware will continue increasing in capability, so as long as we keep an eye out for problems we can make changes to policy before we start causing issues for operators. > If 2005-1 is repealed, how will the space be returned without litigation? > Odds are that it won't and we'll be forced with it with no recourse. And what if the space isn't returned? Say 5 years down the road a new way of multihoming takes off, and we completely repeal 2005-1. All the existing PI holders keep their space, though, and space is only returned through attrition. The number of PI routes in the routing table stops growing, but the capacity of routers keeps growing as it has since day 1. Before too long, router capacity so far exceeds the capacity needed to carry the PI routes that everyone forgets there was ever a problem. -Scott From marla_azinger at eli.net Wed Apr 26 11:20:56 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Wed, 26 Apr 2006 08:20:56 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D0E@wava00s2ke2k01.corp.pvt> Given the pro's and con's of addressing this issue at ARIN/NANOG vs IETF. Who supports taking this to IETF and who supports taking this to ARIN/NANOG? I ask this so that I know which way to push this. It appears there are a few of us willing to work together in order to try and find a resolution. However, I would really like community input on where they would like this resolution "created/pushed". Thank you Marla -----Original Message----- From: Jason Schiller (schiller at uu.net) [mailto:jason.schiller at mci.com] Sent: Tuesday, April 25, 2006 3:05 PM To: Azinger, Marla Cc: Thomas Narten; tony.li at tony.li; ppml at arin.net Subject: Re: [ppml] "Recommended Practices" procedure I also think this effort is worth pursuing. The time frame of the IETF is certainly a factor. And the open process of ARIN and a single living policy document that is ammended and revised seems well suited to this task. I think it seems natural to group number policy and routing policy together as they are closely intertwined. Yet ARIN/NANOG are US centric. What forums would take on this role in other parts of the globe, and how would all of these get synthesized into a single global policy standard? The IETF is a global group. That may be both good and bad. Good that there is a single global standard, but bad if that standard under represents certain regions of the globe. I guess my biggest concern is that I'm not sure there is a critical mass of operators from each of the regions at the IETF. ___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, 25 Apr 2006, Azinger, Marla wrote: > Date: Tue, 25 Apr 2006 14:47:33 -0700 > From: "Azinger, Marla" > To: Thomas Narten , tony.li at tony.li > Cc: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > Also, I feel as though ARIN/NANOG discussion and forum would lead to a more balanced internet community solution. Keeping a document that can reside in a specific "reachable" place would be nice. If it were to reside as a Best business Practice Document with ARIN/NANOG then I feel the ability to "change" it when needed would also be easier to accomplish. > > Marla > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Thomas Narten > Sent: Tuesday, April 25, 2006 2:17 PM > To: tony.li at tony.li > Cc: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > > "Tony Li" writes: > > > > What I see frustrating here is that everyone agrees we need > > > some sort of "internet community agreement" that addresses V6 > > > routing. I hear alot of people asking for this, including > > > myself. Yet I dont hear any specific forum stepping forward > > > to help facilitate this need. > > > What you're asking for is a "routing and addressing architecture". > > Currently, it's really the purview of the IETF, except that they've > > basically abdicated the role. This creates a vacuum, which, as you note > > cries out to be filled. There are multiple ways to make progress here, > > but my favorite is for ARIN to simply push the problem back to the IETF > > and insist on a sensible and scalable solution. > > I think that what people want has a lot to do with operations and > operational practices, an area the IETF struggles with at times. There > is v6ops WG in the IETF: > > http://www.ietf.org/html.charters/v6ops-charter.html > > Reading the charter, my takes is that what I think I'm hearing people > calling for (best practices on things like route filters, is > deaggration allowed or not and under what conditions, etc., etc.) > would be in-scope there. > > Maybe it's time to approach that group (and the ADs), see if there is > a willingness to take on such work in the IETF. What they will want to > see is a critical mass of folk agreeing on the work that needs to be > done (i.e., what kind of document and what is in it) and assurance > that there are enough volunteers to do the actual work. Even if the > work is "officially" housed there, there is no reason why the work > couldn't also be discussed in the various RIR and operations > groups. > > I think the IETF would be as good a place as any to try and do this > work. (And I'm willing to help make this happen if people think this > is worth pursuing.) > > Thomas > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From narten at us.ibm.com Wed Apr 26 11:37:57 2006 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 26 Apr 2006 11:37:57 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: Message from jason.schiller@mci.com of "Tue, 25 Apr 2006 18:13:19 EDT." Message-ID: <200604261537.k3QFbvEN016506@rotala.raleigh.ibm.com> Responding to a number of thoughts... bmanning at vacation.karoshi.com writes: > this is really passing the buck Jason. Asking ARIN to > be your backstop instead of coming up with your own "good > IP stewardship policy" is placing an unwanted burden on > ARIN. I don't think he's asking ARIN to be a backstop. There are frequently situations where the local pressures/interests are in conflict with global ones. Being able to point to a document that is recognized and broadly accepted as a "best current practice" of sorts (that represents the broader and more global interest) is a very useful tool for pushing back on local pressures. What is being asked for is a document that folk can point to so they can say "see, it isn't just me saying this, it's the global community". "Azinger, Marla" writes: > Tony- That would be nice if IETF could do this. The second issue we > face is, we need a solution now, not in a year. Let's be honest, we don't have a document now, and we won't get one now. Can't have one until people start working on it, it gets reviewed, gets revised, etc. This is independent of the venue that is "home" to the work. At the end of the day, how quickly something moves though a venue (IETF, ARIN, etc.) depends a lot on the people doing the work. If people cooperate, review quickly, iterate quickly, etc., work can be done fairly quickly. But if there is no agreement on the content of what is being agreed on, ... But I see no reason why this needs to take more than 6-12 months. But that sort of depends on how big of an effort it is. How many pages of text do we think we are taking about? 10? 100? (I'd expect closer to 10-20), but that needs to be scoped out. "Azinger, Marla" writes: > Also, I feel as though ARIN/NANOG discussion and forum would lead to > a more balanced internet community solution. Keeping a document > that can reside in a specific "reachable" place would be nice. If > it were to reside as a Best business Practice Document with > ARIN/NANOG then I feel the ability to "change" it when needed would > also be easier to accomplish. Having the effort housed in the IETF has the advantage that it's a global organization, and has a well-defined publication facility (RFCs). Doing this in one of the RIR or NOG groups has the issue that it would be more regional. "Jason Schiller (schiller at uu.net)" writes: > And the open process of ARIN and a single living policy document that is > ammended and revised seems well suited to this task. Is a living document what people really want? One problem with "living" is that folk can argue that "it's still under discussion, so it hasn't been agreed to". IMO, the goal should be a "finished" document (i.e., RFC). But it can be made clear that the document will be updated in the future, and an Internet-Draft with updates can be worked on at any time once the base is finished. > Yet ARIN/NANOG are US centric. What forums would take on this role in > other parts of the globe, and how would all of these get synthesized into > a single global policy standard? Have the work housed in the IETF, but do a lot of outreach to the RIR and NOG communities. For example see what has been happening with the shim6 effort (taking it to the NOG groups). Also, one doesn't have to physically go to the IETF to participate. Indeed, it's unclear that face-to-face IETF meetings would be required to actually work on the document. > I guess my biggest concern is that I'm not sure there is a critical mass > of operators from each of the regions at the IETF. Take the document to the operators then. What is most important at the end of the day is that the document itself has been broadly reviewed by operators. No need to come to meetings for that. Thomas From sleibrand at internap.com Wed Apr 26 11:40:24 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 26 Apr 2006 11:40:24 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D0E@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D0E@wava00s2ke2k01.corp.pvt> Message-ID: Marla, I think the best approach might be to bring it up (in a WG or BOF) both at the next IETF and the next joint NANOG/ARIN meeting. One advantage of doing it in the IETF's v6ops WG would be that the IETF has a publication mechanism (RFCs/BCPs). The disadvantage of that, and an advantage of doing it in an operator/RIR forum, is that RFCs can't be updated once published (just obsoleted), so a more "living" document would be less likely to run into staleness problems... -Scott On 04/26/06 at 8:20am -0700, Azinger, Marla wrote: > Given the pro's and con's of addressing this issue at ARIN/NANOG vs IETF. Who supports taking this to IETF and who supports taking this to ARIN/NANOG? > > I ask this so that I know which way to push this. It appears there are a few of us willing to work together in order to try and find a resolution. However, I would really like community input on where they would like this resolution "created/pushed". > > Thank you > Marla > > -----Original Message----- > From: Jason Schiller (schiller at uu.net) [mailto:jason.schiller at mci.com] > Sent: Tuesday, April 25, 2006 3:05 PM > To: Azinger, Marla > Cc: Thomas Narten; tony.li at tony.li; ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > > I also think this effort is worth pursuing. > > The time frame of the IETF is certainly a factor. > > And the open process of ARIN and a single living policy document that is > ammended and revised seems well suited to this task. > > I think it seems natural to group number policy and routing policy > together as they are closely intertwined. > > Yet ARIN/NANOG are US centric. What forums would take on this role in > other parts of the globe, and how would all of these get synthesized into > a single global policy standard? > > The IETF is a global group. That may be both good and bad. Good that > there is a single global standard, but bad if that standard under > represents certain regions of the globe. > > I guess my biggest concern is that I'm not sure there is a critical mass > of operators from each of the regions at the IETF. > > ___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, 25 Apr 2006, Azinger, Marla wrote: > > > Date: Tue, 25 Apr 2006 14:47:33 -0700 > > From: "Azinger, Marla" > > To: Thomas Narten , tony.li at tony.li > > Cc: ppml at arin.net > > Subject: Re: [ppml] "Recommended Practices" procedure > > > > Also, I feel as though ARIN/NANOG discussion and forum would lead to a more balanced internet community solution. Keeping a document that can reside in a specific "reachable" place would be nice. If it were to reside as a Best business Practice Document with ARIN/NANOG then I feel the ability to "change" it when needed would also be easier to accomplish. > > > > Marla > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > > Thomas Narten > > Sent: Tuesday, April 25, 2006 2:17 PM > > To: tony.li at tony.li > > Cc: ppml at arin.net > > Subject: Re: [ppml] "Recommended Practices" procedure > > > > > > "Tony Li" writes: > > > > > > What I see frustrating here is that everyone agrees we need > > > > some sort of "internet community agreement" that addresses V6 > > > > routing. I hear alot of people asking for this, including > > > > myself. Yet I dont hear any specific forum stepping forward > > > > to help facilitate this need. > > > > > What you're asking for is a "routing and addressing architecture". > > > Currently, it's really the purview of the IETF, except that they've > > > basically abdicated the role. This creates a vacuum, which, as you note > > > cries out to be filled. There are multiple ways to make progress here, > > > but my favorite is for ARIN to simply push the problem back to the IETF > > > and insist on a sensible and scalable solution. > > > > I think that what people want has a lot to do with operations and > > operational practices, an area the IETF struggles with at times. There > > is v6ops WG in the IETF: > > > > http://www.ietf.org/html.charters/v6ops-charter.html > > > > Reading the charter, my takes is that what I think I'm hearing people > > calling for (best practices on things like route filters, is > > deaggration allowed or not and under what conditions, etc., etc.) > > would be in-scope there. > > > > Maybe it's time to approach that group (and the ADs), see if there is > > a willingness to take on such work in the IETF. What they will want to > > see is a critical mass of folk agreeing on the work that needs to be > > done (i.e., what kind of document and what is in it) and assurance > > that there are enough volunteers to do the actual work. Even if the > > work is "officially" housed there, there is no reason why the work > > couldn't also be discussed in the various RIR and operations > > groups. > > > > I think the IETF would be as good a place as any to try and do this > > work. (And I'm willing to help make this happen if people think this > > is worth pursuing.) > > > > Thomas > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From william at elan.net Wed Apr 26 14:59:09 2006 From: william at elan.net (william(at)elan.net) Date: Wed, 26 Apr 2006 11:59:09 -0700 (PDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D202100D0E@wava00s2ke2k01.corp.pvt> Message-ID: What exactly makes you think that documents done as part of the discussions at NANOG/ARIN can not go through RFC publication process? Note: RFC-Editor is [supposed to be] independent from IETF and can publish documents as individual submissions or you can bring it as individual submission from another group into IETF if you get Operations AD to sponsor it. On Wed, 26 Apr 2006, Scott Leibrand wrote: > Marla, > > I think the best approach might be to bring it up (in a WG or BOF) both at > the next IETF and the next joint NANOG/ARIN meeting. > > One advantage of doing it in the IETF's v6ops WG would be that the IETF > has a publication mechanism (RFCs/BCPs). The disadvantage of that, and an > advantage of doing it in an operator/RIR forum, is that RFCs can't be > updated once published (just obsoleted), so a more "living" document would > be less likely to run into staleness problems... > > -Scott > > On 04/26/06 at 8:20am -0700, Azinger, Marla wrote: > >> Given the pro's and con's of addressing this issue at ARIN/NANOG vs IETF. Who supports taking this to IETF and who supports taking this to ARIN/NANOG? >> >> I ask this so that I know which way to push this. It appears there are a few of us willing to work together in order to try and find a resolution. However, I would really like community input on where they would like this resolution "created/pushed". >> >> Thank you >> Marla >> >> -----Original Message----- >> From: Jason Schiller (schiller at uu.net) [mailto:jason.schiller at mci.com] >> Sent: Tuesday, April 25, 2006 3:05 PM >> To: Azinger, Marla >> Cc: Thomas Narten; tony.li at tony.li; ppml at arin.net >> Subject: Re: [ppml] "Recommended Practices" procedure >> >> >> I also think this effort is worth pursuing. >> >> The time frame of the IETF is certainly a factor. >> >> And the open process of ARIN and a single living policy document that is >> ammended and revised seems well suited to this task. >> >> I think it seems natural to group number policy and routing policy >> together as they are closely intertwined. >> >> Yet ARIN/NANOG are US centric. What forums would take on this role in >> other parts of the globe, and how would all of these get synthesized into >> a single global policy standard? >> >> The IETF is a global group. That may be both good and bad. Good that >> there is a single global standard, but bad if that standard under >> represents certain regions of the globe. >> >> I guess my biggest concern is that I'm not sure there is a critical mass >> of operators from each of the regions at the IETF. >> >> ___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, 25 Apr 2006, Azinger, Marla wrote: >> >>> Date: Tue, 25 Apr 2006 14:47:33 -0700 >>> From: "Azinger, Marla" >>> To: Thomas Narten , tony.li at tony.li >>> Cc: ppml at arin.net >>> Subject: Re: [ppml] "Recommended Practices" procedure >>> >>> Also, I feel as though ARIN/NANOG discussion and forum would lead to a more balanced internet community solution. Keeping a document that can reside in a specific "reachable" place would be nice. If it were to reside as a Best business Practice Document with ARIN/NANOG then I feel the ability to "change" it when needed would also be easier to accomplish. >>> >>> Marla >>> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >>> Thomas Narten >>> Sent: Tuesday, April 25, 2006 2:17 PM >>> To: tony.li at tony.li >>> Cc: ppml at arin.net >>> Subject: Re: [ppml] "Recommended Practices" procedure >>> >>> >>> "Tony Li" writes: >>> >>>>> What I see frustrating here is that everyone agrees we need >>>>> some sort of "internet community agreement" that addresses V6 >>>>> routing. I hear alot of people asking for this, including >>>>> myself. Yet I dont hear any specific forum stepping forward >>>>> to help facilitate this need. >>> >>>> What you're asking for is a "routing and addressing architecture". >>>> Currently, it's really the purview of the IETF, except that they've >>>> basically abdicated the role. This creates a vacuum, which, as you note >>>> cries out to be filled. There are multiple ways to make progress here, >>>> but my favorite is for ARIN to simply push the problem back to the IETF >>>> and insist on a sensible and scalable solution. >>> >>> I think that what people want has a lot to do with operations and >>> operational practices, an area the IETF struggles with at times. There >>> is v6ops WG in the IETF: >>> >>> http://www.ietf.org/html.charters/v6ops-charter.html >>> >>> Reading the charter, my takes is that what I think I'm hearing people >>> calling for (best practices on things like route filters, is >>> deaggration allowed or not and under what conditions, etc., etc.) >>> would be in-scope there. >>> >>> Maybe it's time to approach that group (and the ADs), see if there is >>> a willingness to take on such work in the IETF. What they will want to >>> see is a critical mass of folk agreeing on the work that needs to be >>> done (i.e., what kind of document and what is in it) and assurance >>> that there are enough volunteers to do the actual work. Even if the >>> work is "officially" housed there, there is no reason why the work >>> couldn't also be discussed in the various RIR and operations >>> groups. >>> >>> I think the IETF would be as good a place as any to try and do this >>> work. (And I'm willing to help make this happen if people think this >>> is worth pursuing.) >>> >>> Thomas >>> >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Wed Apr 26 16:23:50 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Apr 2006 13:23:50 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D0E@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D0E@wava00s2ke2k01.corp.pv t> Message-ID: <0EBA66FAA3161246680563B1@imac-en0.delong.sj.ca.us> I think the documents should be produced under IETF charter, most likely. However, I think that unlike most IETF processes which gain little input from actual operational concerns because they do not embrace NANOG and RIRs as well as would be ideal, the discussions should include much greater outreach to the RIR communities and NANOG and similar operationally focused organizations. Owen --On April 26, 2006 8:20:56 AM -0700 "Azinger, Marla" wrote: > Given the pro's and con's of addressing this issue at ARIN/NANOG vs IETF. > Who supports taking this to IETF and who supports taking this to > ARIN/NANOG? > > I ask this so that I know which way to push this. It appears there are a > few of us willing to work together in order to try and find a resolution. > However, I would really like community input on where they would like > this resolution "created/pushed". > > Thank you > Marla > > -----Original Message----- > From: Jason Schiller (schiller at uu.net) [mailto:jason.schiller at mci.com] > Sent: Tuesday, April 25, 2006 3:05 PM > To: Azinger, Marla > Cc: Thomas Narten; tony.li at tony.li; ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > > I also think this effort is worth pursuing. > > The time frame of the IETF is certainly a factor. > > And the open process of ARIN and a single living policy document that is > ammended and revised seems well suited to this task. > > I think it seems natural to group number policy and routing policy > together as they are closely intertwined. > > Yet ARIN/NANOG are US centric. What forums would take on this role in > other parts of the globe, and how would all of these get synthesized into > a single global policy standard? > > The IETF is a global group. That may be both good and bad. Good that > there is a single global standard, but bad if that standard under > represents certain regions of the globe. > > I guess my biggest concern is that I'm not sure there is a critical mass > of operators from each of the regions at the IETF. > > ___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, 25 Apr 2006, Azinger, Marla wrote: > >> Date: Tue, 25 Apr 2006 14:47:33 -0700 >> From: "Azinger, Marla" >> To: Thomas Narten , tony.li at tony.li >> Cc: ppml at arin.net >> Subject: Re: [ppml] "Recommended Practices" procedure >> >> Also, I feel as though ARIN/NANOG discussion and forum would lead to a >> more balanced internet community solution. Keeping a document that can >> reside in a specific "reachable" place would be nice. If it were to >> reside as a Best business Practice Document with ARIN/NANOG then I feel >> the ability to "change" it when needed would also be easier to >> accomplish. >> >> Marla >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> Thomas Narten >> Sent: Tuesday, April 25, 2006 2:17 PM >> To: tony.li at tony.li >> Cc: ppml at arin.net >> Subject: Re: [ppml] "Recommended Practices" procedure >> >> >> "Tony Li" writes: >> >> > > What I see frustrating here is that everyone agrees we need >> > > some sort of "internet community agreement" that addresses V6 >> > > routing. I hear alot of people asking for this, including >> > > myself. Yet I dont hear any specific forum stepping forward >> > > to help facilitate this need. >> >> > What you're asking for is a "routing and addressing architecture". >> > Currently, it's really the purview of the IETF, except that they've >> > basically abdicated the role. This creates a vacuum, which, as you >> > note cries out to be filled. There are multiple ways to make progress >> > here, but my favorite is for ARIN to simply push the problem back to >> > the IETF and insist on a sensible and scalable solution. >> >> I think that what people want has a lot to do with operations and >> operational practices, an area the IETF struggles with at times. There >> is v6ops WG in the IETF: >> >> http://www.ietf.org/html.charters/v6ops-charter.html >> >> Reading the charter, my takes is that what I think I'm hearing people >> calling for (best practices on things like route filters, is >> deaggration allowed or not and under what conditions, etc., etc.) >> would be in-scope there. >> >> Maybe it's time to approach that group (and the ADs), see if there is >> a willingness to take on such work in the IETF. What they will want to >> see is a critical mass of folk agreeing on the work that needs to be >> done (i.e., what kind of document and what is in it) and assurance >> that there are enough volunteers to do the actual work. Even if the >> work is "officially" housed there, there is no reason why the work >> couldn't also be discussed in the various RIR and operations >> groups. >> >> I think the IETF would be as good a place as any to try and do this >> work. (And I'm willing to help make this happen if people think this >> is worth pursuing.) >> >> Thomas >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Lee.Howard at stanleyassociates.com Wed Apr 26 18:03:13 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 26 Apr 2006 18:03:13 -0400 Subject: [ppml] Just say *NO* to PI space -- or howto make it less destructive Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB401E4DEAD@CL-S-EX-1.stanleyassociates.com> Can't stand HTML email. Matt Petach wrote: >>Dampening works, for the value of "works" which equals "suppressing new >>(better?) information about the path to a network," which is often equal >>to "misrouting data because a new path was not calculated." If, >>following >>this proposed policy, aggressive dampening becomes commonly required by >>operators to maintain their networks, it might have a bearing on support >>for this policy. >Concern was raised about end networks changing routing state too quickly >for modern CPUs to handle; the way we handle that today is to dampen >successive transitions once they reach a certain threshold level. I see no >reason why the current mechanism in use today in the IPv4 world should >not work just as well on the IPv6 network. The upper bound of number of prefixes is higher. There's a difference between a flap and a topology change. >>If it takes six months of testing to be confident in a new core router, >>and you replace 5% of your routers every week, and you ignore all other >>maintenance, you could replace your core in a year. Another year for >>distribution and edge. Any other kinds of devices take another year, >>for testing and rollout. That's assuming you employ as many engineers >>as needed, and ignore other work. > The point I was making is that if we limit IP allocation policies > based on hardware upgrade cycles, we shackle ourselves to > the ISP that decides that they should be able to run just fine > with their IGS or AGS+, and therefore no additional prefixes > can be allocated because they're unwilling _or_ unable to > upgrade. Are there ISPs whose upgrade cycle has prohibited them from replacing their AGS+en? My example suggested 2-3 years from the date a box is released before the entire network can be upgraded to it. One consideration for policy is whether we can see a problem far enough out to prevent it. The implied question here is, "If IPv6 adoption following 2005-1 is fast, will we be able to either change the policy or deploy fast enough routers before breaking things?" Your answer may vary, but it seems to me to be a reasonable question. > If we start putting limits on what can be assigned due to > concerns about what some providers may be unwilling to > upgrade in their core, are we also going to entertain > proposals to limit IPv4 allocations so that those selfsame > providers won't have to upgrade their IPv4 routers either? > > Let's be realistic. We don't have any limits on how much > IPv4 deaggregation we'll support, We don't? We can accept 2^24 prefixes? > we just trust the routers > to scale up to support the growth--why are we attempting > to treat IPv6 differently? Do we not expect IPv6 to take > over for IPv4 in the forseeable future? It is mathematically possible, though the probability is debatable, that the number of IPv6 prefixes will grow faster than router capacity. Is there a point where the routers released 2-3 years ago can't handle today's routes? >>> Provider independence is here already, period. It's too late to try >>> to put >>> the horse back in the barn >> ? > I mean 'In the IPv4 internet of today, multihoming is a fact of > life, and is expected by businesses. If IPv6 is ever intended > to be more than an academic mastubatory exercise, the > policies associated with IPv6 allocations will need to support > a similar or better level of provider independence for businesses > as the existing IPv4 allocation policies.' I know I'm old-fashioned, but I like to see professional language in a professional setting. But thank you for clarifying that point. > To that end, yes, I support 2005-1. > IPv6 without provider independent allocations is broken, > and will never be widely adopted. 2005-1 is one possible > suggestion on how to fix it. I support 2005-1 as a well > thought out means to fix an otherwise broken protocol. OK, now I understand your position. Thank you. >> I've never >> tried rocket science, but I know of some nuclear physicists who find >> consensus-building to be challenging. > That's nice. If we don't come to consensus and move > forward, this rocket is never going to lift off. And if IPv6 > doesn't take off, then we'll see some *real* challenges > when IPv4 space starts getting scarce, and the black > market for v4 space starts to solidify. There isn't even consensus on that. Intelligent people have different expectations of this protocol; some think the rocket will explode. > I'm supporting 2005-1 because I'd prefer to see those > prefixes handled on the IPv6 internet. It sounds like > you'd prefer to say 'no' to IPv6 PI space, and instead > have your routing slots consumed by IPv4 prefixes > instead, and that's certainly your choice. I'm not sure why prefixes in IPv6 are better than in IPv4, but it doesn't much matter to me: I only have a default route. I don't have a strong opinion on 2005-1. But I like threads that support or oppose a specific policy proposal, and it seemed like this one was becoming a global rant of "PI Good!" versus "PI Bad!" I'm happy now, thanks. > Matt Lee From christopher.morrow at gmail.com Wed Apr 26 23:14:15 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 26 Apr 2006 23:14:15 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <8D20EB19-AEC0-4AFA-93AC-53574FAC18D2@multicasttech.com> References: <8D20EB19-AEC0-4AFA-93AC-53574FAC18D2@multicasttech.com> Message-ID: <75cb24520604262014n54def165m565c08209557f36c@mail.gmail.com> On 4/25/06, Marshall Eubanks wrote: > Well, I am not going to say that I disagree about that either, but > it's pretty clear to me that there are interested people here who do > not generally > come to NANOGs or ARIN meetings. Of course, many of them don't come > to IETF's either... is there not a reason to pursue it at both? The problem that Jason (and I think Marla) are dancing around is that in an RIR based solution, or any solution that is not 'globally agreed upon', lends itself to a failed solution. Today, MOST providers will accept and re-advertise a /24 route, this seems to be a 'globally agreed upon' boundary. This is good and bad (debate later). In v6 this hasn't really been set yet, though with 2005-1 passing (potentially, depending on AC I suppose?) the boundary will be /48... it'll quickly be 'all /48' as well I predict. > On Apr 25, 2006, at 6:13 PM, Jason Schiller (schiller at uu.net) wrote: > > > Not that I dis-agree, but why not a BOF at the next NANOG? > > > > ___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, 25 Apr 2006, Marshall Eubanks wrote: > > > >> Date: Tue, 25 Apr 2006 18:08:43 -0400 > >> From: Marshall Eubanks > >> To: "Azinger, Marla" > >> Cc: Thomas Narten , ppml at arin.net > >> Subject: Re: [ppml] "Recommended Practices" procedure > >> > >> This issue had a big discussion about this at the RIPE-52 meeting now > >> on-going in Istanbul, and I believe > >> that a resolution similar to 2005-1 is likely to result from it. Are > >> you going to ignore them and the other communities. > >> > >> I would suggest a BOF at the Montreal IETF. Here are the parameters > >> for doing this : > >> > >> ----- > >> -- Cut-off date for requesting a session: Monday, June 5 at 17:00 > >> ET > >> (21:00 > >> UTC/GMT). > >> -- Preliminary agenda published for comment: Friday, June 9 by > >> midnight ET. > >> -- Cut-off date for requests to reschedule a session: Wednesday, > >> June > >> 14 at > >> 09:00 ET (13:00 UTC/GMT). > >> -- Final schedule published: Monday, June 19 before midnight ET. > >> > >> Submitting Requests for Working Group and BOF Sessions > >> > >> Please submit requests to schedule your Working Group sessions using > >> the "IETF > >> Meeting Session Request Tool," a Web-based tool for submitting all of > >> the > >> information that the Secretariat requires to schedule your sessions. > >> ----- > >> > >> Regards > >> Marshall > >> > >> On Apr 25, 2006, at 5:47 PM, Azinger, Marla wrote: > >> > >>> Also, I feel as though ARIN/NANOG discussion and forum would lead > >>> to a more balanced internet community solution. Keeping a document > >>> that can reside in a specific "reachable" place would be nice. If > >>> it were to reside as a Best business Practice Document with ARIN/ > >>> NANOG then I feel the ability to "change" it when needed would also > >>> be easier to accomplish. > >>> > >>> Marla > >>> > >>> -----Original Message----- > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On > >>> Behalf Of > >>> Thomas Narten > >>> Sent: Tuesday, April 25, 2006 2:17 PM > >>> To: tony.li at tony.li > >>> Cc: ppml at arin.net > >>> Subject: Re: [ppml] "Recommended Practices" procedure > >>> > >>> > >>> "Tony Li" writes: > >>> > >>>>> What I see frustrating here is that everyone agrees we need > >>>>> some sort of "internet community agreement" that addresses V6 > >>>>> routing. I hear alot of people asking for this, including > >>>>> myself. Yet I dont hear any specific forum stepping forward > >>>>> to help facilitate this need. > >>> > >>>> What you're asking for is a "routing and addressing architecture". > >>>> Currently, it's really the purview of the IETF, except that they've > >>>> basically abdicated the role. This creates a vacuum, which, as > >>>> you note > >>>> cries out to be filled. There are multiple ways to make progress > >>>> here, > >>>> but my favorite is for ARIN to simply push the problem back to the > >>>> IETF > >>>> and insist on a sensible and scalable solution. > >>> > >>> I think that what people want has a lot to do with operations and > >>> operational practices, an area the IETF struggles with at times. > >>> There > >>> is v6ops WG in the IETF: > >>> > >>> http://www.ietf.org/html.charters/v6ops-charter.html > >>> > >>> Reading the charter, my takes is that what I think I'm hearing > >>> people > >>> calling for (best practices on things like route filters, is > >>> deaggration allowed or not and under what conditions, etc., etc.) > >>> would be in-scope there. > >>> > >>> Maybe it's time to approach that group (and the ADs), see if > >>> there is > >>> a willingness to take on such work in the IETF. What they will > >>> want to > >>> see is a critical mass of folk agreeing on the work that needs to be > >>> done (i.e., what kind of document and what is in it) and assurance > >>> that there are enough volunteers to do the actual work. Even if the > >>> work is "officially" housed there, there is no reason why the work > >>> couldn't also be discussed in the various RIR and operations > >>> groups. > >>> > >>> I think the IETF would be as good a place as any to try and do this > >>> work. (And I'm willing to help make this happen if people think > >>> this > >>> is worth pursuing.) > >>> > >>> Thomas > >>> > >>> _______________________________________________ > >>> PPML mailing list > >>> PPML at arin.net > >>> http://lists.arin.net/mailman/listinfo/ppml > >>> _______________________________________________ > >>> PPML mailing list > >>> PPML at arin.net > >>> http://lists.arin.net/mailman/listinfo/ppml > >> > >> _______________________________________________ > >> PPML mailing list > >> PPML at arin.net > >> http://lists.arin.net/mailman/listinfo/ppml > >> > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From christopher.morrow at gmail.com Wed Apr 26 23:17:11 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 26 Apr 2006 23:17:11 -0400 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal In-Reply-To: References: Message-ID: <75cb24520604262017k3efcc64geda523276063c4d8@mail.gmail.com> On 4/25/06, George Kuzmowycz wrote: > David Williamson wrote on 04/25/2006 9:42:40 AM: > > Sounds like I better go read the draft. I agree that ownership > rights > > would be a problem > > Why is the (potential) ownership of IP addresses a Bad Thing? > I think from the "users don't 'own' ip space" current stance on ip address 'ownership' ... you are currently 'assigned' space from ARIN for your use you do not 'own' it in the same sense as you 'own' the bubble-gum you bought from the local grocer... 'you' being the royal form of course. -Chris From jason.schiller at mci.com Wed Apr 26 23:56:35 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Wed, 26 Apr 2006 23:56:35 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <75cb24520604262014n54def165m565c08209557f36c@mail.gmail.com> Message-ID: Chris, Yes... and no So the problem is that each of the forums have the pros and cons... ITEF is global, but BCPs will have to continously be obsoleted, and not easily referenced. IETF maybe lacks enough operators support. ARIN seems to have a good consensus building forum, and has the IP address policy people. Routing policy seems intertwined with IP address policy. ARIN is not global, and would require some sort of Policy Resource Organization (PRO) to synchronize policy between RIRs. The OGs have more operators and may have more useful input on what the concerns about a given routing policy might be. The NOGs lack any support for publishing, or even consensus building, and is not global. Somehow a mixture of the three seems most optimal... ___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, 26 Apr 2006, Christopher Morrow wrote: > Date: Wed, 26 Apr 2006 23:14:15 -0400 > From: Christopher Morrow > To: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > On 4/25/06, Marshall Eubanks wrote: > > Well, I am not going to say that I disagree about that either, but > > it's pretty clear to me that there are interested people here who do > > not generally > > come to NANOGs or ARIN meetings. Of course, many of them don't come > > to IETF's either... > > is there not a reason to pursue it at both? The problem that Jason > (and I think Marla) are dancing around is that in an RIR based > solution, or any solution that is not 'globally agreed upon', lends > itself to a failed solution. > > Today, MOST providers will accept and re-advertise a /24 route, this > seems to be a 'globally agreed upon' boundary. This is good and bad > (debate later). In v6 this hasn't really been set yet, though with > 2005-1 passing (potentially, depending on AC I suppose?) the boundary > will be /48... it'll quickly be 'all /48' as well I predict. > > > On Apr 25, 2006, at 6:13 PM, Jason Schiller (schiller at uu.net) wrote: > > > > > Not that I dis-agree, but why not a BOF at the next NANOG? > > > > > > ___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, 25 Apr 2006, Marshall Eubanks wrote: > > > > > >> Date: Tue, 25 Apr 2006 18:08:43 -0400 > > >> From: Marshall Eubanks > > >> To: "Azinger, Marla" > > >> Cc: Thomas Narten , ppml at arin.net > > >> Subject: Re: [ppml] "Recommended Practices" procedure > > >> > > >> This issue had a big discussion about this at the RIPE-52 meeting now > > >> on-going in Istanbul, and I believe > > >> that a resolution similar to 2005-1 is likely to result from it. Are > > >> you going to ignore them and the other communities. > > >> > > >> I would suggest a BOF at the Montreal IETF. Here are the parameters > > >> for doing this : > > >> > > >> ----- > > >> -- Cut-off date for requesting a session: Monday, June 5 at 17:00 > > >> ET > > >> (21:00 > > >> UTC/GMT). > > >> -- Preliminary agenda published for comment: Friday, June 9 by > > >> midnight ET. > > >> -- Cut-off date for requests to reschedule a session: Wednesday, > > >> June > > >> 14 at > > >> 09:00 ET (13:00 UTC/GMT). > > >> -- Final schedule published: Monday, June 19 before midnight ET. > > >> > > >> Submitting Requests for Working Group and BOF Sessions > > >> > > >> Please submit requests to schedule your Working Group sessions using > > >> the "IETF > > >> Meeting Session Request Tool," a Web-based tool for submitting all of > > >> the > > >> information that the Secretariat requires to schedule your sessions. > > >> ----- > > >> > > >> Regards > > >> Marshall > > >> > > >> On Apr 25, 2006, at 5:47 PM, Azinger, Marla wrote: > > >> > > >>> Also, I feel as though ARIN/NANOG discussion and forum would lead > > >>> to a more balanced internet community solution. Keeping a document > > >>> that can reside in a specific "reachable" place would be nice. If > > >>> it were to reside as a Best business Practice Document with ARIN/ > > >>> NANOG then I feel the ability to "change" it when needed would also > > >>> be easier to accomplish. > > >>> > > >>> Marla > > >>> > > >>> -----Original Message----- > > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On > > >>> Behalf Of > > >>> Thomas Narten > > >>> Sent: Tuesday, April 25, 2006 2:17 PM > > >>> To: tony.li at tony.li > > >>> Cc: ppml at arin.net > > >>> Subject: Re: [ppml] "Recommended Practices" procedure > > >>> > > >>> > > >>> "Tony Li" writes: > > >>> > > >>>>> What I see frustrating here is that everyone agrees we need > > >>>>> some sort of "internet community agreement" that addresses V6 > > >>>>> routing. I hear alot of people asking for this, including > > >>>>> myself. Yet I dont hear any specific forum stepping forward > > >>>>> to help facilitate this need. > > >>> > > >>>> What you're asking for is a "routing and addressing architecture". > > >>>> Currently, it's really the purview of the IETF, except that they've > > >>>> basically abdicated the role. This creates a vacuum, which, as > > >>>> you note > > >>>> cries out to be filled. There are multiple ways to make progress > > >>>> here, > > >>>> but my favorite is for ARIN to simply push the problem back to the > > >>>> IETF > > >>>> and insist on a sensible and scalable solution. > > >>> > > >>> I think that what people want has a lot to do with operations and > > >>> operational practices, an area the IETF struggles with at times. > > >>> There > > >>> is v6ops WG in the IETF: > > >>> > > >>> http://www.ietf.org/html.charters/v6ops-charter.html > > >>> > > >>> Reading the charter, my takes is that what I think I'm hearing > > >>> people > > >>> calling for (best practices on things like route filters, is > > >>> deaggration allowed or not and under what conditions, etc., etc.) > > >>> would be in-scope there. > > >>> > > >>> Maybe it's time to approach that group (and the ADs), see if > > >>> there is > > >>> a willingness to take on such work in the IETF. What they will > > >>> want to > > >>> see is a critical mass of folk agreeing on the work that needs to be > > >>> done (i.e., what kind of document and what is in it) and assurance > > >>> that there are enough volunteers to do the actual work. Even if the > > >>> work is "officially" housed there, there is no reason why the work > > >>> couldn't also be discussed in the various RIR and operations > > >>> groups. > > >>> > > >>> I think the IETF would be as good a place as any to try and do this > > >>> work. (And I'm willing to help make this happen if people think > > >>> this > > >>> is worth pursuing.) > > >>> > > >>> Thomas > > >>> > > >>> _______________________________________________ > > >>> PPML mailing list > > >>> PPML at arin.net > > >>> http://lists.arin.net/mailman/listinfo/ppml > > >>> _______________________________________________ > > >>> PPML mailing list > > >>> PPML at arin.net > > >>> http://lists.arin.net/mailman/listinfo/ppml > > >> > > >> _______________________________________________ > > >> PPML mailing list > > >> PPML at arin.net > > >> http://lists.arin.net/mailman/listinfo/ppml > > >> > > > > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From christopher.morrow at gmail.com Thu Apr 27 00:42:54 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 27 Apr 2006 00:42:54 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: References: Message-ID: <75cb24520604262142n4c0c732akbb9b7a6ef241529d@mail.gmail.com> > > It appears that most people at the last want to make a policy for policy's > > sake. > > I disagree. I think most people are in favor of 2005-1 because they > recognize that this PI policy is better than no PI policy. > I think, actually, it was more: "we need to help jumpstart v6, nothing would do that better than making folks that need to deploy it not be tied to a single provider or broken multihoming schemes"... but that's probably not horribly relevant anymore. > > There are many other things that haven't been looked at in addition > > to just IPv4 and IPv6 tables. I haven't heard or seen any studies of the > > impact that VPNs have in addition and even get more nervous when > > discussions on PEv6 are brought up. > > I'm not sure what special impact PI space would have on VPNs or PEv6. Can > you elaborate? In particular, do you have any idea how many PI routes it > would take to start breaking either technology (given current hardware)? > So, I think the problem might be: Someone has a large IP network, they overlayed a largeish 'VPN service' on that network. What routing growth problem are they having? or will they have with ipv6? If you use some form of the numbers from tony/jason/geoff and try to predict current v4 table + 'current' v6 table growth what impact will this have on the above example? I'd say that you might be able to stay the VPN routes mean a 'static' increase on whatever the math above shows you as a growth rate. At the very least, the additional growth rate from the VPN routes is going to be highly provider dependent. (so hard to predict globally) > > As others have mentioned, historically temporary solutions aren't. I > > believe that we are making the same mistakes as we did when v4 was first > > rolled out with a /48 out of a reserved /44 per PI request. How large is > > this PI swamp that is being proposed? > > The number of PI allocations will be small, at least at first. The number > of entities that have gotten IPv4 PI is small (less than 10,000 IIRC), and > you have to qualify for IPv4 PI to get IPv6 PI under 2005-1. Hardware > will continue increasing in capability, so as long as we keep an eye out > for problems we can make changes to policy before we start causing issues > for operators. > I think I agree with Aaron here, they just won't ever come back... there are legacy /24's assigned that no one can recover today. there will be 'legacy' /48's (or 44's or whatever the decision on size is) assigned tomorrow and never recovered. > > If 2005-1 is repealed, how will the space be returned without litigation? > > Odds are that it won't and we'll be forced with it with no recourse. > > And what if the space isn't returned? Say 5 years down the road a new way > of multihoming takes off, and we completely repeal 2005-1. All the > existing PI holders keep their space, though, and space is only returned > through attrition. The number of PI routes in the routing table stops > growing, but the capacity of routers keeps growing as it has since day 1. > Before too long, router capacity so far exceeds the capacity needed to > carry the PI routes that everyone forgets there was ever a problem. > that is a nice utopia, I think it's several generations of equipment off in the future though :( From christopher.morrow at gmail.com Thu Apr 27 01:14:48 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 27 Apr 2006 01:14:48 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <75cb24520604262142n4c0c732akbb9b7a6ef241529d@mail.gmail.com> References: <75cb24520604262142n4c0c732akbb9b7a6ef241529d@mail.gmail.com> Message-ID: <75cb24520604262214q2a125cf8mf8de5ab9450e51eb@mail.gmail.com> apparently I'm dim today.. I forgot to enter my 'vote': "I do NOT support this proposal" (which I may have said earlier, I lost track) sorry. On 4/27/06, Christopher Morrow wrote: > > > It appears that most people at the last want to make a policy for policy's > > > sake. > > > > I disagree. I think most people are in favor of 2005-1 because they > > recognize that this PI policy is better than no PI policy. > > > > I think, actually, it was more: "we need to help jumpstart v6, nothing > would do that better than making folks that need to deploy it not be > tied to a single provider or broken multihoming schemes"... but that's > probably not horribly relevant anymore. From jason.schiller at mci.com Thu Apr 27 01:10:51 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 27 Apr 2006 01:10:51 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: Message-ID: I am against this policy. It seems that people really want multi-homing badly to make IPv6 work. Heidi Hinden's first law: When you want it bad, you get it bad, and most people want it in the worst way. What concerns me are three things: 1. Enterprise customer who want PI addresses or useful multi-homing, and don't care about the problems it creates for the large ISPs that carry full routes. (That's their problem.) In reality it is everyone's problem if they want to transit one of these ISPs, or use best path routing (carry full routes and not just a default to a transit provider). Lets not forget that router vendors are behind the curve on port speeds too. Are these vendors more likely to solve the routing table problem that affects only the largest ISPs or focus on port speed problems that affect many large enterprise customers? 2. The concern people are being short sited and since there are only 1,000 routes in the IPv6 Internet table that this will not be a problem any time soon. 3. The concern that we haven't done enough research to know if the vendors will be able to stay far enough ahead of the route table growth to not have a problem. It is not enough for vendors to build the routers big enough in time. If it takes 3 years to fully replace a network, and the router vendors are only two years ahead of the curve, then I only get 2/3 through my upgrades before having to start a new set of upgrades. Never mind being able to depreciate the cost of the router over 5 years. We have to understand what it means to make a long term commitment to deaggregation. I don't hear the six largest ISPs standing up and saying we did some studies of what the routing table will look like in five to ten years, and have talked to our vendors and we don't think it will be a problem. (Leo this is your cue to say this will only affect about 6 ISPs and maybe the world is better off without them.) The point Aaron was trying to make was in reference to my projections. For example I want to buy new routers today. It takes 2 years to certify and fully deploy the router throughout the network. I want the router to live in the network for 5 years to depreciate the value. That means if by 2011 there is wide spread adoption of IPv6 the router will need to support 1.3M routes. This example does not take into consideration L3VPN routes, or routes from converging multiple networks onto a single chassis. ___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, 26 Apr 2006, Arin Archive wrote: > Date: Wed, 26 Apr 2006 02:15:53 -0400 (EDT) > From: Arin Archive > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 > > I am against this policy. > It appears that most people at the last want to make a policy for policy's > sake. There are many other things that haven't been looked at in addition > to just IPv4 and IPv6 tables. I haven't heard or seen any studies of the > impact that VPNs have in addtion and even get more nervious when > discussions on PEv6 are brought up. As others have mentioned, historically > temporary solutions aren't. I believe that we are making the same mistakes > as we did when v4 was first rolled out with a /48 out of a reserved /44 > per PI request. How large is this PI swamp that is being proposed? > If 2005-1 is repealed, how will the space be returned without litigation? > Odds are that it won't and we'll be forced with it with no recourse. > > Aaron Dudek > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From jason.schiller at mci.com Thu Apr 27 01:47:08 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 27 Apr 2006 01:47:08 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <75cb24520604262142n4c0c732akbb9b7a6ef241529d@mail.gmail.com> Message-ID: On Thu, 27 Apr 2006, Christopher Morrow wrote: > > > As others have mentioned, historically temporary solutions aren't. I > > > believe that we are making the same mistakes as we did when v4 was first > > > rolled out with a /48 out of a reserved /44 per PI request. How large is > > > this PI swamp that is being proposed? > > > I think I agree with Aaron here, they just won't ever come back... > there are legacy /24's assigned that no one can recover today. there > will be 'legacy' /48's (or 44's or whatever the decision on size is) > assigned tomorrow and never recovered. > The routes in the Internet routing table will likely be more specific than a /48 assuming people want to slice and dice their aggregate to do traffic engineering... I haven't done a study to see how many slices people typically need. One way to look at it is to consider that since /56s are assigned to soho then maybe this makes the /56 the new /24, and providers will allow more specifics upto /56. In other words, small sites will have just enough PA space to take up one slot in the Internet routing table and make multihoming work. ___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. From bmanning at vacation.karoshi.com Thu Apr 27 02:53:15 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 27 Apr 2006 06:53:15 +0000 Subject: [ppml] Just say *NO* to PI space -- or howto make it less destructive In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401E4DEAD@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB401E4DEAD@CL-S-EX-1.stanleyassociates.com> Message-ID: <20060427065315.GA16949@vacation.karoshi.com.> > > the ISP that decides that they should be able to run just fine > > with their IGS or AGS+, and therefore no additional prefixes > > can be allocated because they're unwilling _or_ unable to > > upgrade. > > Are there ISPs whose upgrade cycle has prohibited them from > replacing their AGS+en? My example suggested 2-3 years from the > date a box is released before the entire network can be upgraded there is at least one... but thats 'cause CHAOSnet was dropped in later platforms --bill > Lee > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Thu Apr 27 03:22:29 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Apr 2006 00:22:29 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: The relation between addressing policy and routing policy is an artifact of a bigger mistake. While in V4 due to several constraints, it was necessary to restrict addressing policy to meet immediate routing needs, this should not become a long-term factor and should be resolved in v6. Owen --On April 26, 2006 11:56:35 PM -0400 "Jason Schiller (schiller at uu.net)" wrote: > Chris, > > Yes... and no > > So the problem is that each of the forums have the pros and cons... ITEF > is global, but BCPs will have to continously be obsoleted, and not easily > referenced. IETF maybe lacks enough operators support. > > ARIN seems to have a good consensus building forum, and has the IP address > policy people. Routing policy seems intertwined with IP address > policy. ARIN is not global, and would require some sort of Policy > Resource Organization (PRO) to synchronize policy between RIRs. > > The OGs have more operators and may have more useful input on what the > concerns about a given routing policy might be. The NOGs lack any support > for publishing, or even consensus building, and is not global. > > Somehow a mixture of the three seems most optimal... > > ___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, 26 Apr 2006, Christopher Morrow wrote: > >> Date: Wed, 26 Apr 2006 23:14:15 -0400 >> From: Christopher Morrow >> To: ppml at arin.net >> Subject: Re: [ppml] "Recommended Practices" procedure >> >> On 4/25/06, Marshall Eubanks wrote: >> > Well, I am not going to say that I disagree about that either, but >> > it's pretty clear to me that there are interested people here who do >> > not generally >> > come to NANOGs or ARIN meetings. Of course, many of them don't come >> > to IETF's either... >> >> is there not a reason to pursue it at both? The problem that Jason >> (and I think Marla) are dancing around is that in an RIR based >> solution, or any solution that is not 'globally agreed upon', lends >> itself to a failed solution. >> >> Today, MOST providers will accept and re-advertise a /24 route, this >> seems to be a 'globally agreed upon' boundary. This is good and bad >> (debate later). In v6 this hasn't really been set yet, though with >> 2005-1 passing (potentially, depending on AC I suppose?) the boundary >> will be /48... it'll quickly be 'all /48' as well I predict. >> >> > On Apr 25, 2006, at 6:13 PM, Jason Schiller (schiller at uu.net) wrote: >> > >> > > Not that I dis-agree, but why not a BOF at the next NANOG? >> > > >> > > ___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, 25 Apr 2006, Marshall Eubanks wrote: >> > > >> > >> Date: Tue, 25 Apr 2006 18:08:43 -0400 >> > >> From: Marshall Eubanks >> > >> To: "Azinger, Marla" >> > >> Cc: Thomas Narten , ppml at arin.net >> > >> Subject: Re: [ppml] "Recommended Practices" procedure >> > >> >> > >> This issue had a big discussion about this at the RIPE-52 meeting >> > >> now on-going in Istanbul, and I believe >> > >> that a resolution similar to 2005-1 is likely to result from it. Are >> > >> you going to ignore them and the other communities. >> > >> >> > >> I would suggest a BOF at the Montreal IETF. Here are the parameters >> > >> for doing this : >> > >> >> > >> ----- >> > >> -- Cut-off date for requesting a session: Monday, June 5 at 17:00 >> > >> ET >> > >> (21:00 >> > >> UTC/GMT). >> > >> -- Preliminary agenda published for comment: Friday, June 9 by >> > >> midnight ET. >> > >> -- Cut-off date for requests to reschedule a session: Wednesday, >> > >> June >> > >> 14 at >> > >> 09:00 ET (13:00 UTC/GMT). >> > >> -- Final schedule published: Monday, June 19 before midnight ET. >> > >> >> > >> Submitting Requests for Working Group and BOF Sessions >> > >> >> > >> Please submit requests to schedule your Working Group sessions using >> > >> the "IETF >> > >> Meeting Session Request Tool," a Web-based tool for submitting all >> > >> of the >> > >> information that the Secretariat requires to schedule your sessions. >> > >> ----- >> > >> >> > >> Regards >> > >> Marshall >> > >> >> > >> On Apr 25, 2006, at 5:47 PM, Azinger, Marla wrote: >> > >> >> > >>> Also, I feel as though ARIN/NANOG discussion and forum would lead >> > >>> to a more balanced internet community solution. Keeping a document >> > >>> that can reside in a specific "reachable" place would be nice. If >> > >>> it were to reside as a Best business Practice Document with ARIN/ >> > >>> NANOG then I feel the ability to "change" it when needed would also >> > >>> be easier to accomplish. >> > >>> >> > >>> Marla >> > >>> >> > >>> -----Original Message----- >> > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >> > >>> Behalf Of >> > >>> Thomas Narten >> > >>> Sent: Tuesday, April 25, 2006 2:17 PM >> > >>> To: tony.li at tony.li >> > >>> Cc: ppml at arin.net >> > >>> Subject: Re: [ppml] "Recommended Practices" procedure >> > >>> >> > >>> >> > >>> "Tony Li" writes: >> > >>> >> > >>>>> What I see frustrating here is that everyone agrees we need >> > >>>>> some sort of "internet community agreement" that addresses V6 >> > >>>>> routing. I hear alot of people asking for this, including >> > >>>>> myself. Yet I dont hear any specific forum stepping forward >> > >>>>> to help facilitate this need. >> > >>> >> > >>>> What you're asking for is a "routing and addressing architecture". >> > >>>> Currently, it's really the purview of the IETF, except that >> > >>>> they've basically abdicated the role. This creates a vacuum, >> > >>>> which, as you note >> > >>>> cries out to be filled. There are multiple ways to make progress >> > >>>> here, >> > >>>> but my favorite is for ARIN to simply push the problem back to the >> > >>>> IETF >> > >>>> and insist on a sensible and scalable solution. >> > >>> >> > >>> I think that what people want has a lot to do with operations and >> > >>> operational practices, an area the IETF struggles with at times. >> > >>> There >> > >>> is v6ops WG in the IETF: >> > >>> >> > >>> http://www.ietf.org/html.charters/v6ops-charter.html >> > >>> >> > >>> Reading the charter, my takes is that what I think I'm hearing >> > >>> people >> > >>> calling for (best practices on things like route filters, is >> > >>> deaggration allowed or not and under what conditions, etc., etc.) >> > >>> would be in-scope there. >> > >>> >> > >>> Maybe it's time to approach that group (and the ADs), see if >> > >>> there is >> > >>> a willingness to take on such work in the IETF. What they will >> > >>> want to >> > >>> see is a critical mass of folk agreeing on the work that needs to >> > >>> be done (i.e., what kind of document and what is in it) and >> > >>> assurance that there are enough volunteers to do the actual work. >> > >>> Even if the work is "officially" housed there, there is no reason >> > >>> why the work couldn't also be discussed in the various RIR and >> > >>> operations groups. >> > >>> >> > >>> I think the IETF would be as good a place as any to try and do this >> > >>> work. (And I'm willing to help make this happen if people think >> > >>> this >> > >>> is worth pursuing.) >> > >>> >> > >>> Thomas >> > >>> >> > >>> _______________________________________________ >> > >>> PPML mailing list >> > >>> PPML at arin.net >> > >>> http://lists.arin.net/mailman/listinfo/ppml >> > >>> _______________________________________________ >> > >>> PPML mailing list >> > >>> PPML at arin.net >> > >>> http://lists.arin.net/mailman/listinfo/ppml >> > >> >> > >> _______________________________________________ >> > >> PPML mailing list >> > >> PPML at arin.net >> > >> http://lists.arin.net/mailman/listinfo/ppml >> > >> >> > > >> > >> > _______________________________________________ >> > PPML mailing list >> > PPML at arin.net >> > http://lists.arin.net/mailman/listinfo/ppml >> > >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Apr 27 04:03:08 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Apr 2006 01:03:08 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: References: Message-ID: <6D094C1352F436FB1E267BE1@odpwrbook.hq.netli.lan> I promise, last post for a while on this topic. --On April 27, 2006 1:10:51 AM -0400 "Jason Schiller (schiller at uu.net)" wrote: > I am against this policy. > > It seems that people really want multi-homing badly to make IPv6 work. > > Heidi Hinden's first law: When you want it bad, you get it bad, and most > people want it in the worst way. > Notwithstanding the fact that I have no idea who Heidi Hinden is or why I should obey her laws... I don't think that's an accurate analysis of the situation at all. I think that there is a large(ish) portion of the network community which does not remember the pre-CIDR internet and does not remember or realize that the limitations imposed by CIDR were once viewed as a very bad thing which broke a lot of functionality. There are a small number of people who do remember the pre-CIDR internet. Interestingly, both of these groups are subdivided into two groups... In those who do not remember the pre-CIDR internet, we have group A, mostly comprised of large(ish) ISPs who like the customer-lock-in aspects of CIDR and don't want to let go of that marketing leverage. These are the ones which also want to use reductio ad absurdum arguments about the size of the mythical global routing table and address the fact that once upon a time, the BGP table exceeded the capabilities of the AGS+ routers available at the time. On the other hand, we have group B, who don't remember pre-CIDR, but, they want their PI space like they have in v4, and, they want to be able to multi-home, and, they don't want some overly-complex solution that requires support on far-end hosts they have no way to influence or control. Now, in the case of those that remember, we also have two groups. Group C, much like group A, is largely comprised of people from large(ish) ISPs who espouse largely the same position. In fact, any distinction between group A and group C is purely an academic exercise as near as I can tell. On the other side of those who remember, we have group D. This group is not ignorant of the limitations of the routing system. We are not (yes, I consider myself a member of group D) unaware of the issues with routing table growth in the current architecture. However, we also remember that one of the primary goals for the development of v6 was to FIX THIS. So far, it hasn't been fixed. Between v4 and v6, really, nothing changed in terms of routing. However, for both v4 and v6, I am convinced that these issues are far less urgent today, although I agree the problem has not been completely solved. Fortunately, I think the problem _CAN_ be solved and that we have approximately 10 years to solve it. Here's how I figure it: 1. The current routing table is comprised of just over 20,000 active ASNs. The current v4 Prefix:ASN ratio is close to 8:1 on average, with the peaks advertisers being several hundred and the lows being 1. In the v6 world, this number should be much much closer to 1:1, probably somewhere around 2:1 will be realistic. That means that the current routing table translated to a v6 world will shrink to less than 50,000 routes. That should give us lots of headroom for v6 growth as v4 becomes less and less prevalant and eventually is not globally routed. 2. It is unlikely that the internet will see anywhere near the explosive growth of the 90s in the next 5-10 years. Even if it did, we would still stay well short of 160,000 v6 routes which is well under most estimates I've heard for current hardware capability. As such, there shouldn't be much of a problem for at least 10 years. 3. The large(ish) ISPs comprise the majority of the operational focus in the IETF, and, indeed have been a strong enough force there that they were able to get RFCs cranked out which attempted to preserve a completely provider-dependent addressing model for the v6 internet. As such, faced with building a scalable routing system or waiting for the network to implode, I would hope that they will start working towards a more scalable solution, such as ID/LOC splits. 4. I think that if IETF and large(ish) ISPs and router vendors work towards a solution, 10 years is more than enough time for development, testing, and, early deployment. 5. Vendor focus, in my experience, tends to be towards making the large(ish) ISPs happy and the majority of enterprises are a secondary consideration. This makes sense when you consider that the average large(ish) ISP spends several million dollars per year with their router vendor(s) of choice, while the rest of the world is significantly less per enterprise (in most cases) spread over a much wider collection of sales representatives. In most sales-oriented organizations (which as near as I can tell, all the hardware vendors are today), the sales rep with the largest dollar value tends to have the largest say in the feature priorities. > What concerns me are three things: > > 1. Enterprise customer who want PI addresses or useful multi-homing, and > don't care about the problems it creates for the large ISPs that carry > full routes. (That's their problem.) > > In reality it is everyone's problem > if they want to transit one of these ISPs, or use best path routing > (carry full routes and not just a default to a transit provider). > > Lets not forget that router vendors are behind the curve on port speeds > too. Are these vendors more likely to solve the routing table problem > that affects only the largest ISPs or focus on port speed problems that > affect many large enterprise customers? > Yes, in today's architecture, if we assume that this policy will double the number of ASNs and that the advertising ratio for v6 does come out close to 2:1, we'll see a v6 routing table, fully deployed, of about 100,000 routes. That's still smaller than the current v4 table, and, that's assuming that the number of ASNs issued doubles (which I think is unlikely in the next 10 years). > 2. The concern people are being short sited and since there are only 1,000 > routes in the IPv6 Internet table that this will not be a problem any time > soon. > No... People supporting this policy aren't looking at 1,000 v6 routes and saying "see... v6 table has lots of room". They're saying "Look: v6 is failing to gain acceptance. Further, looking at the number of ASNs in v4, we can extrapolate that v6 will have better aggregation per ASN, and, thus we shouldn't see more than 2:1 prefix ratio in v6. That means that the current v4 internet could be re-implemented in v6 with less than 50,000 routes (vs. the current 180,000+)." I don't mind that you disagree with our argument, but, please don't call us short-sighted or ignorant using a different argument than the one we presented. > 3. The concern that we haven't done enough research to know if the vendors > will be able to stay far enough ahead of the route table growth to not > have a problem. It is not enough for vendors to build the routers big > enough in time. If it takes 3 years to fully replace a network, and the > router vendors are only two years ahead of the curve, then I only get 2/3 > through my upgrades before having to start a new set of upgrades. Never > mind being able to depreciate the cost of the router over 5 years. > I think it doesn't matter. ISPs will route what ISPs will route. Having ARIN addressing policy protect ISPs from the legitimate demands of their customers is an inappropriate use of policy in my opinion. ARIN should neither encourage nor prohibit the routing of any prefix by any ISP. That should be a contractual matter between the ISPs and their peers and customers. Having said that, I also think that the only real way to address the true needs of the community is by coming up with a scalable routing solution. I do not believe that any routing solution based on using the same number for end system identifier (ID) and topological locator (LOC) can scale. I do think that there are possible advantages to having some level of geographic distribution of these PI addresses and I encourage the research and effort that is being done toward that end at this time. However, I hope that IETF will see this policy (and similar discussions starting to happen in other RIRs) and start working on a viable long-term routing protocol so that we can deploy it before this really becomes an issue. > We have to understand what it means to make a long term commitment to > deaggregation. I don't hear the six largest ISPs standing up and saying > we did some studies of what the routing table will look like in five to > ten years, and have talked to our vendors and we don't think it will be a > problem. > You're right. Instead, you hear a reasonable sampling of their customers standing up and saying "We're not going to take this any more" about the provider-lock-in based addressing of the CIDR world. > The point Aaron was trying to make was in reference to my > projections. For example I want to buy new routers today. It takes 2 > years to certify and fully deploy the router throughout the network. I > want the router to live in the network for 5 years to depreciate the > value. That means if by 2011 there is wide spread adoption of IPv6 the > router will need to support 1.3M routes. This example does not take into > consideration L3VPN routes, or routes from converging multiple networks > onto a single chassis. > Where on earth did you get the idea that there would be 650,000 active ASNs by 2011? You're going to have to work real hard to show me any reasonable projection that predicts such a value. If you're claiming that would be the sum of v4 and v6 routes, I would argue that if v6 adoption is that wide by 2011, the majority of the core would be v6 and v4 routes would become native only in local pockets. Across the core, they would be v4 in v6 tunnels, so, the big 6 would have alternatives to carrying both sets of routes in any one router. Also if v6 adoption is that widespread, I think that the number of people still using v4 would be significantly reduced if, for no other reason, ISPs will start charging extra to preserve v4 infrastructure by then. Bottom line, I think your projections are simply unrealistic by any rational version of expectations for the next 10 years, let alone 5. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From stephen at sprunk.org Thu Apr 27 04:49:11 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 27 Apr 2006 03:49:11 -0500 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 References: Message-ID: <030201c669d7$745a06e0$56b3db18@ssprunk> Thus spake "Jason Schiller (schiller at uu.net)" > On Thu, 27 Apr 2006, Christopher Morrow wrote: >> I think I agree with Aaron here, they just won't ever come back... >> there are legacy /24's assigned that no one can recover today. there >> will be 'legacy' /48's (or 44's or whatever the decision on size is) >> assigned tomorrow and never recovered. > > The routes in the Internet routing table will likely be more specific than > a /48 assuming people want to slice and dice their aggregate to do > traffic engineering... I haven't done a study to see how many slices > people typically need. It's interesting to note that, according to the Weekly Routing Table Report, roughly half of all routes in the v4 DFZ are longer than the RIR maxima. This implies that there is no real problem in the v4 world with deaggregation even at the level of 180k routes -- otherwise ISPs would be filtering. If you disagree with deaggregation for the purpose of traffic engineering, which IMHO is perfectly valid if you're not being paid for those routing slots, then filter anything longer than RIR maxima and be done with it. In PIv6 land, this would be a /48. Now, if you're claiming there will be sufficient /48s to cause you problems, that's another matter entirely. > One way to look at it is to consider that since /56s are assigned to > soho then maybe this makes the /56 the new /24, and providers will > allow more specifics upto /56. In other words, small sites will have > just enough PA space to take up one slot in the Internet routing table > and make multihoming work. While I understand your concern about this, the proposal under discussion only refers to /48s for large end sites. Please don't conflate the two discussions. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From stephen at sprunk.org Thu Apr 27 04:50:14 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 27 Apr 2006 03:50:14 -0500 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 References: Message-ID: <030301c669d7$99b8ad60$56b3db18@ssprunk> Thus spake "Arin Archive" > I am against this policy. > It appears that most people at the last want to make a policy for policy's > sake. IMHO, we're trying to meet a real business need that ARIN members and the community at large are faced with. I think you're right in a sense that many folks don't think 2005-1 is the ideal policy, but that's not quite the same as saying we're doing it for the sake of doing it. In the real world, one often has to choose the least bad from among many bad alternatives (and no good ones). Consensus is that 2005-1 is less bad than having no PIv6 policy at all. > As others have mentioned, historically temporary solutions aren't. I > believe that we are making the same mistakes as we did when v4 > was first rolled out with a /48 out of a reserved /44 per PI request. > How large is this PI swamp that is being proposed? Please define "swamp". If each AS gets a single PIv6 prefix, is that really a swamp? One of the major problems with v4 was that a single org would get dozens (or hundreds) of separate blocks; we're definitely not repeating that mistake. We're also not repeating the mistake of handing out blocks without any sort of oversight or "renewal" process. There's no explicit limit on the number of prefixes to be assigned under this policy, but the intent is that it be no more than the number of ASNs assigned. At worst, this means PIv6 will present an order of magnitude fewer routes than PIv4; i.e. as long as v4 is still alive, v6 will not be the problem. In short, we may be making a mistake here, but if so it's very different from the mistakes we made with v4. > If 2005-1 is repealed, how will the space be returned without litigation? > Odds are that it won't and we'll be forced with it with no recourse. If PIv6 space becomes a serious operational concern to folks in the DFZ, they can simply filter the entire space since it's to be from a distinct block from LIR allocations. This is another major difference from PIv4, where ISPs had no way of knowing what was PA and what was PI. IANAL, but I'm pretty sure that if 2005-1 were repealed, ARIN could refuse to renew PIv6 assignments and they'd all be gone within a year. There's even other language in the NRPM that states ARIN can, in extreme cases, revoke assignments and/or allocations that violate policy, so this isn't something new. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From jeroen at unfix.org Thu Apr 27 05:01:11 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 27 Apr 2006 11:01:11 +0200 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <6D094C1352F436FB1E267BE1@odpwrbook.hq.netli.lan> References: <6D094C1352F436FB1E267BE1@odpwrbook.hq.netli.lan> Message-ID: <1146128471.3048.44.camel@firenze.zurich.ibm.com> [large snip of a very good writeup] On Thu, 2006-04-27 at 01:03 -0700, Owen DeLong wrote: [..] > building a scalable routing system or waiting for the network > to implode, I would hope that they will start working towards > a more scalable solution, such as ID/LOC splits. Indeed. A possible solution like shim6 might take still quite a number of years to be developped and deployed, but the current solution "injecting those PI spaces into the global routing table" can scale most likely for the time being. One thing that especially large ISP/Transits's (I saw something like Sprint/MCI/Verizon 'voting against PI) seem to be confusing about is that there is a difference between "address space" and "routing entries". "PI" does not mean that it will end up in the DFZ, it will most likely, but it might not. A company can decide to internally use the PI space, so that they have globally unique address space, but when accessing services on the internet they might proxy (or NAT or shim6) this address space and thus effectively connect from the address space their upstream provider provids them. For the coming years though indeed most PI blocks will pop up in the DFZ. But what is the issue there? If you are a large transit, you simply let your client PAY for announcing that prefix into the DFZ. No pay? -> No route. That is if you really are that scared that your hardware can't handle it, and if it can't, something I said to a certain "Large Tier 1 Transit" before: UPGRADE! (and when the economics don't work out for you, you might want to start rethinking if you are in the wrong business or not ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From Michael.Dillon at btradianz.com Thu Apr 27 08:11:37 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 27 Apr 2006 13:11:37 +0100 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D0E@wava00s2ke2k01.corp.pvt> Message-ID: > Given the pro's and con's of addressing this issue at ARIN/NANOG vs > IETF. Who supports taking this to IETF and who supports taking this > to ARIN/NANOG? Irrelevant question. Without some sort of consensus on specifics, there is no forum that will address this issue in an "official" capacity. To start with, people need to agree on a framework for developing industry consensus and some set of questions to put forth for ISPs to answer. --Michael Dillon From Michael.Dillon at btradianz.com Thu Apr 27 08:19:30 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 27 Apr 2006 13:19:30 +0100 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: Message-ID: > 2. The concern people are being short sited and since there are only 1,000 > routes in the IPv6 Internet table that this will not be a problem any time > soon. > That means if by 2011 there is wide spread adoption of IPv6 the > router will need to support 1.3M routes. And YOU are being short-sighted if you think that ARIN policy cannot adapt itself to changing situations before 2011. During that timespan of approximately 5 years, ARIN could easily manage revision of the IPv6 PI policy 3 times, if that is needed in order to respond to new developments. --Michael Dillon From stephen at sprunk.org Thu Apr 27 08:19:43 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 27 Apr 2006 07:19:43 -0500 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 References: Message-ID: <036001c669f4$dd8119c0$56b3db18@ssprunk> Thus spake "Jason Schiller (schiller at uu.net)" > I am against this policy. > > It seems that people really want multi-homing badly to make IPv6 work. > > Heidi Hinden's first law: When you want it bad, you get it bad, and most > people want it in the worst way. We'd prefer a better solution, really, but the IETF has failed to provide us one. Since multihoming is a fundamental business requirement for enterprises and PI is the only way to make multihoming work today, either enterprises get PIv6 or v6 doesn't happen. Please keep in mind that we don't like this situation any more than you do. > What concerns me are three things: > > 1. Enterprise customer who want PI addresses or useful multi-homing, and > don't care about the problems it creates for the large ISPs that carry > full routes. (That's their problem.) > > In reality it is everyone's problem > if they want to transit one of these ISPs, or use best path routing > (carry full routes and not just a default to a transit provider). OTOH, one could say that large ISPs don't care about the problems that PA space causes enterprises. 2005-1 is an attempt to find a compromise that's acceptable to both sides. > Lets not forget that router vendors are behind the curve on port speeds > too. Are these vendors more likely to solve the routing table problem > that affects only the largest ISPs or focus on port speed problems that > affect many large enterprise customers? Vendors, like any other business, will solve the problems that result in the highest profits. It's not surprising, therefore, that the vendor-dominated IETF has failed to produce a new IDR paradigm that makes routing table growth (and thus constant upgrades) unnecessary. > 2. The concern people are being short sited and since there are only 1,000 > routes in the IPv6 Internet table that this will not be a problem any time > soon. That's hardly what we're saying. What we're saying is that the floodgates are wide, wide open for PIv4 yet there's a paltry ~9650 non-transit ASes in ARIN-land and multihoming is growing slower than Moore's Law. There is no rational reason to expect that the number of ASes will increase significantly solely due to 2005-1 since we're reusing the existing bar; if there is a rush for ASNs, the v4 table will grow more rapidly than the v6 table due to the inherent prefix-per-ASN differences. PIv6 will be the least of ISPs' worries if your fears turn out to be correct. Now, if we had set the bar for PIv6 lower than for PIv4, I'd agree with you that there's a serious danger of an overwhelming land rush, but that's not the case. The bar is the same, and that was deliberate. > 3. The concern that we haven't done enough research to know if the vendors > will be able to stay far enough ahead of the route table growth to not > have a problem. It is not enough for vendors to build the routers big > enough in time. If it takes 3 years to fully replace a network, and the > router vendors are only two years ahead of the curve, then I only get 2/3 > through my upgrades before having to start a new set of upgrades. Never > mind being able to depreciate the cost of the router over 5 years. > > We have to understand what it means to make a long term commitment to > deaggregation. I don't hear the six largest ISPs standing up and saying > we did some studies of what the routing table will look like in five to > ten years, and have talked to our vendors and we don't think it will be a > problem. OTOH, I don't see any ISPs standing up and saying they did some studies of what the routing table will look like in five to ten years, and have talked to our vendors and we _do_ think it will be a problem. [sic] > The point Aaron was trying to make was in reference to my > projections. For example I want to buy new routers today. It takes 2 > years to certify and fully deploy the router throughout the network. I > want the router to live in the network for 5 years to depreciate the > value. That means if by 2011 there is wide spread adoption of IPv6 the > router will need to support 1.3M routes. This example does not take into > consideration L3VPN routes, or routes from converging multiple networks > onto a single chassis. I'd like to hear why you think you'll need to support 1.3M IPv6 routes in five years. Particularly, I'd like to hear what you think is wrong with the pro-PIv6 camp's assertions that we should see 1-2 routes per ASN and that the growth in ASNs will be at or near historical levels. If we're wrong, we'd really like to know how and why so that we can find a better compromise. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From Michael.Dillon at btradianz.com Thu Apr 27 08:24:22 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 27 Apr 2006 13:24:22 +0100 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: Message-ID: > The routes in the Internet routing table will likely be more specific than > a /48 assuming people want to slice and dice their aggregate to do traffic > engineering... I support 2005-1 and I would continue to support it if the AC adjusts the language to include the same language prohibiting deaggregation that is currently applied to LIR allocations. In that case, there will be NO routes more specific that a /48 and PI holders will have no ability to do traffic engineering in this way. If, by chance, the AC cannot add this to the policy then I would support a modification at the autumn meeting of ARIN. The end result is that PI holders get no more than 6 months to play with longer prefixes before we bring the PI policy closer in line with LIR policy. At this point in time, the number of routes we are talking about are small enough that there is no real concern. In addition, ISPs could easily block prefixes longer than a /48 if they choose to. --Michael Dillon From Michael.Dillon at btradianz.com Thu Apr 27 08:38:58 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 27 Apr 2006 13:38:58 +0100 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <1146128471.3048.44.camel@firenze.zurich.ibm.com> Message-ID: > "PI" does not mean that it will end up in the DFZ, it will > most likely, but it might not. A company can decide to internally use > the PI space, so that they have globally unique address space, but when > accessing services on the internet they might proxy (or NAT or shim6) > this address space and thus effectively connect from the address space > their upstream provider provids them. Indeed so. My company operates a private internet for a thousand or so companies. Although most addresses used on this internet are assigned by us, some companies have their own allocations. This is an example of allocations (in this case both PA and PI) that do not consume global routing table slots. We are not the only company to run such an internet and in the future I expect to see more and more of this kind of architecture. Because these are IP internets, the companies involved are fully justified in registering globally unique IP address ranges. In fact, they often have security policies in place which verify that the allocations are in the RIR whois system. If you look at any analysis of IP address consumption you will see that there is a significant chunk of address space which is not announced in the global routing system. There is NOT a direct tie-in between a PI allocation and a global routing table slot. > For the coming years though indeed > most PI blocks will pop up in the DFZ. But what is the issue there? If > you are a large transit, you simply let your client PAY for announcing > that prefix into the DFZ. No pay? -> No route. That is if you really are > that scared that your hardware can't handle it, and if it can't, > something I said to a certain "Large Tier 1 Transit" before: UPGRADE! > (and when the economics don't work out for you, you might want to start > rethinking if you are in the wrong business or not ;) Indeed true. If the routing table growth is increasing your costs by forcing earlier than expected upgrades, you should be shifting those costs on to the customers who are generating the additional slot consumption. Perhaps you should be discussing this issue internally with your finance and legal people to make sure your contracts cover this eventuality. ARIN does not tell you to provide service for free. --Michael Dillon From kloch at hotnic.net Thu Apr 27 09:44:58 2006 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 27 Apr 2006 09:44:58 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <75cb24520604262014n54def165m565c08209557f36c@mail.gmail.com> References: <8D20EB19-AEC0-4AFA-93AC-53574FAC18D2@multicasttech.com> <75cb24520604262014n54def165m565c08209557f36c@mail.gmail.com> Message-ID: <4450CADA.6060408@hotnic.net> Christopher Morrow wrote: > Today, MOST providers will accept and re-advertise a /24 route, this > seems to be a 'globally agreed upon' boundary. This is good and bad > (debate later). In v6 this hasn't really been set yet, though with > 2005-1 passing (potentially, depending on AC I suppose?) the boundary > will be /48... it'll quickly be 'all /48' as well I predict. It seems that many networks already accept /48's today, as a direct result of a lack of PI policy. The generous minimum allocation size of /32 means that accepting all /48's (or even /44's) is a really bad idea. Unless wasteful /32's are used for PI assignments, ISP's will have no choice but to have different minimum prefix size limits by range. This is why it is important to have a large well known and static range (like a /16) set aside for PI assignments. At that point it is no different than the /48 rules needed for the critical infrastructure /48's. Whether a /16 should be set aside by each RIR or one globally is an interesting question. - Kevin From George.Kuzmowycz at aipso.com Thu Apr 27 09:50:39 2006 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Thu, 27 Apr 2006 09:50:39 -0400 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Message-ID: "Christopher Morrow" 04/26/2006 wrote on 11:17:11 PM: > On 4/25/06, George Kuzmowycz wrote: >> David Williamson wrote on 04/25/2006 9:42:40 AM: >> > Sounds like I better go read the draft. I agree that ownership >> rights >> > would be a problem >> >> Why is the (potential) ownership of IP addresses a Bad Thing? >> > > I think from the "users don't 'own' ip space" current stance on ip > address 'ownership' ... you are currently 'assigned' space from ARIN > for your use you do not 'own' it in the same sense as you 'own' the > bubble-gum you bought from the local grocer... 'you' being the royal > form of course. I'm sorry, but this explanation is simply a tautology. I recognize I may sound like a troll (I'm not) or a dimwit (perhaps arguable), but I still don't see it. I recognize that 'allocation' as opposed to 'ownership' is current policy with a substantial history. I recognize that this made sense in the environment which existed 20 years ago, and that altering that policy, at least wrt IPv4 addresses, would instantly "monetize" those decades-old allocations. I can even understand the argument of why this might be a bad thing (although I'm sure some holders of /8's might see it differently.) What I don't see is why this line of reasoning is being repeated. It seems, here, just like one of those "everyone knows" arguments, and I guess I'm just not part of "everyone". From tli at tropos.com Thu Apr 27 10:39:49 2006 From: tli at tropos.com (Tony Li) Date: Thu, 27 Apr 2006 07:39:49 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: Message-ID: <000001c66a08$71bb9800$9d01a8c0@tropos.com> > > That means if by 2011 there is wide spread adoption of IPv6 the > > router will need to support 1.3M routes. > > And YOU are being short-sighted if you think that > ARIN policy cannot adapt itself to changing situations > before 2011. During that timespan of approximately > 5 years, ARIN could easily manage revision of the > IPv6 PI policy 3 times, if that is needed in order > to respond to new developments. Supposed that we approve 2005-1. If things take off, we could then deploy several hundred thousand routes (on the order of the v4 network today), and then we try to decide that we want to reverse ourselves and have several thousand people undo the work that they've done and deploy a different solution? Somehow, I don't think that even ARIN has the political clout to pull that off in practice. This is exactly why extreme care is necessary here: the genie *CANNOT* be put back into the bottle. Tony P.s. If it's not blindingly obvious, I oppose 2005-1. From Michael.Dillon at btradianz.com Thu Apr 27 11:01:40 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 27 Apr 2006 16:01:40 +0100 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <000001c66a08$71bb9800$9d01a8c0@tropos.com> Message-ID: > > And YOU are being short-sighted if you think that > > ARIN policy cannot adapt itself to changing situations > > before 2011. During that timespan of approximately > > 5 years, ARIN could easily manage revision of the > > IPv6 PI policy 3 times, if that is needed in order > > to respond to new developments. > > Supposed that we approve 2005-1. If things take off, we could then > deploy several hundred thousand routes Before the August 11th deadline for the next ARIN meeting? I don't think so. > (on the order of the v4 network > today), and then we try to decide that we want to reverse ourselves and > have several thousand people undo the work that they've done and deploy > a different solution? You are completely missing the point. There is an ARIN member meeting roughly once every 6 months. New policies proposed more than 60 days prior to the meeting can be passed by the meeting and will make it through the last call, AC and BoT within a couple of more months or so. There is no way that kind of growth could happen in such a short period of time. But, let's assume, for the sake of argument, that these new PI addresses really take off in a big way and projections show that it will be in the tens of thousands by year end. The BoT does have the power to halt all PI applications until the members can reconsider the policy. This would be an extremely unusual action but anyone familiar with ARIN allocation statistics knows that the numbers of PI allocations you are talking about describe an EXTREMELY UNUSUAL SITUATION. > This is exactly why extreme care is necessary here: the genie *CANNOT* > be put back into the bottle. Nobody has proposed that genies be let out of bottles. What has been proposed is loosening the belt for a while to enable businesses the freedom to deploy IPv6 networks the way that they want to. Belts can be progressively loosened or tightened as many times as is necessary. If IPv6 PI does prove to be a bad move, it is BETTER FOR ARIN TO MAKE THE MISTAKE and then correct it. Otherwise we risk being the target of restraint of trade lawsuits. It simply is not legally prudent to disallow PI allocations in IPv6 and it is not legally prudent for the representatives of large ISPs to vote against 2005-1 without having consulted their legal/regulatory departments. --Michael Dillon From michel at arneill-py.sacramento.ca.us Thu Apr 27 11:17:34 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 27 Apr 2006 08:17:34 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Message-ID: > Jeroen Massar wrote: > [large snip of a very good writeup] Very good writeup from Owen indeed. > ... That is if you really are that scared that your hardware can't > handle it, and if it can't, something I said to a certain "Large > Tier 1 Transit" before: UPGRADE! (and when the economics don't work > out for you, you might want to start rethinking if you are in the > wrong business or not ;) Exactly. About upgrades: 1. _If_ the growth of the routing table requires upgrades, it will require upgrades from everyone. The argument "it would force me to upgrade" is flawed because everyone is in the same boat. ISPs are a competitive business and if some disappear in the process, be it; that's in the nature of things. 2. Even if the growth of the routing table does not require upgrades vendors _will_ discontinue products in order to move on. Part of it is good reasons (changes in manufacturing process, difficult to find older components, etc) and another part of it is pure greed but it does happen. This entire industry is based on product life cycles. Upgrades are part of life. They're part of what's called "cost of being in business". Michel. From vaf at cisco.com Thu Apr 27 12:18:19 2006 From: vaf at cisco.com (Vince Fuller) Date: Thu, 27 Apr 2006 09:18:19 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: References: <000001c66a08$71bb9800$9d01a8c0@tropos.com> Message-ID: <20060427161819.GA23742@vaf-lnx1.cisco.com> I ask myself "oh why do I waste keystrokes on this?" but then I do it anyway. If it is true that one definition of insanity is doing the same thing over and over while expecting the same result, then I should really stop trying to provide intelligent explainations about scaling issues on NANOG... > > Supposed that we approve 2005-1. If things take off, we could then > > deploy several hundred thousand routes > > Before the August 11th deadline for the next ARIN > meeting? I don't think so. > > > (on the order of the v4 network > > today), and then we try to decide that we want to reverse ourselves and > > have several thousand people undo the work that they've done and deploy > > a different solution? > > You are completely missing the point. There is an > ARIN member meeting roughly once every 6 months. New > policies proposed more than 60 days prior to the meeting > can be passed by the meeting and will make it through the > last call, AC and BoT within a couple of more months or so. > There is no way that kind of growth could happen in such > a short period of time. No, you are completely missing the point. Establishing a policy that defines "provider independent space" sets a precedent that, for all practical purposes, will not be revokable. Once early adopters are granted "PI space", the genie will be surely and truly out of the bottle; those recipients of a valuable commodity will not be easily persuaded to give it up nor will their service providers cut-off paying customers by ceasing to route "de-authorized" prefixes. Those assignhments will be permanent, just as all SRI-NIC-era assignments ("the swamp space") are still filling the IPv4 routing table more than 10 years after they were last granted. Future applicants will rightly cry "foul" when told that they aren't going to be given the same "PI space" that early adopters were given. > But, let's assume, for the sake of argument, that > these new PI addresses really take off in a big way and > projections show that it will be in the tens of thousands > by year end. The BoT does have the power to halt all PI > applications until the members can reconsider the policy. > This would be an extremely unusual action but anyone familiar > with ARIN allocation statistics knows that the numbers of > PI allocations you are talking about describe an > EXTREMELY UNUSUAL SITUATION. Nonsense. Once something is given it is almost impossible to get it back. And creating a two-tiered society of "early adopters with PI space" vs. "late adopters who get something less valuable" is going to run into all sorts of issues. And the hundreds of thousands of routes that are of concern to those who think about "big Internet" scaling problems are what we *will* see if a "PI space" policy is adopted. Not by years end but most certainly if ipv6 is widely adopted in the absence of a scalable multihoming solution (and no, the existing ipv6 strict topology-based addressing plan doesn't cut it, either; the protocol MUST be fixed to replace the "address" with a topology-based locator and a endpoint id that does not need to ever be renumbered once assigned before ipv6 can be ubiqitously deployed). > Nobody has proposed that genies be let out of bottles. > What has been proposed is loosening the belt for a while > to enable businesses the freedom to deploy IPv6 networks > the way that they want to. Belts can be progressively loosened > or tightened as many times as is necessary. > > If IPv6 PI does prove to be a bad move, it is BETTER FOR > ARIN TO MAKE THE MISTAKE and then correct it. Otherwise we > risk being the target of restraint of trade lawsuits. It simply > is not legally prudent to disallow PI allocations in IPv6 and > it is not legally prudent for the representatives of large > ISPs to vote against 2005-1 without having consulted their > legal/regulatory departments. Ooh, the "restraint of trade boogieman". I would be rather more concerned over lawsuits regarding unfair and inconsistant business practices should an RIR establish the precedent of granting a valuable asset ("PI space") to early adopters and then refusing to offer equal treatment to later adopters. Or of tring to revoke the use of an existing "PI space" allocation that is in use for critical business purposes. Some organizations were good enough to transition off of pre-RIR IPv4 assignments (anybody remember net 36.0.0.0) because of a sense of community and of doing good for the collective; that sense of community has long since vanished from the commercial Internet, so past behavior is most certainly not a good indicator of future behavior. Fix the routing and addressing architecture *NOW*; don't try to kludge around it and hope that it is possible to retrofit a fix later. --Vince From pesherb at yahoo.com Thu Apr 27 12:23:25 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Thu, 27 Apr 2006 09:23:25 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <6D094C1352F436FB1E267BE1@odpwrbook.hq.netli.lan> Message-ID: <20060427162325.25295.qmail@web54703.mail.yahoo.com> > I do not believe that any routing solution based on using the same number for end > system identifier (ID) and topological locator (LOC) can scale. Agree. IPv6 address is long enough to break ID/LOC link allowing routing solution to be based e.g. on LOC only and leaving ID function to a complete customer discretion as an imbedded purpose. Peter --- Owen DeLong wrote: > I promise, last post for a while on this topic. > > > --On April 27, 2006 1:10:51 AM -0400 "Jason Schiller (schiller at uu.net)" > wrote: > > > I am against this policy. > > > > It seems that people really want multi-homing badly to make IPv6 work. > > > > Heidi Hinden's first law: When you want it bad, you get it bad, and most > > people want it in the worst way. > > > Notwithstanding the fact that I have no idea who Heidi Hinden is or > why I should obey her laws... I don't think that's an accurate analysis > of the situation at all. > > I think that there is a large(ish) portion of the network community > which does not remember the pre-CIDR internet and does not remember > or realize that the limitations imposed by CIDR were once viewed as > a very bad thing which broke a lot of functionality. There are a > small number of people who do remember the pre-CIDR internet. > > Interestingly, both of these groups are subdivided into two groups... > > In those who do not remember the pre-CIDR internet, we have group A, > mostly comprised of large(ish) ISPs who like the customer-lock-in > aspects of CIDR and don't want to let go of that marketing leverage. > These are the ones which also want to use reductio ad absurdum > arguments about the size of the mythical global routing table and > address the fact that once upon a time, the BGP table exceeded the > capabilities of the AGS+ routers available at the time. > > On the other hand, we have group B, who don't remember pre-CIDR, > but, they want their PI space like they have in v4, and, they want > to be able to multi-home, and, they don't want some overly-complex > solution that requires support on far-end hosts they have no way > to influence or control. > > Now, in the case of those that remember, we also have two groups. > Group C, much like group A, is largely comprised of people from > large(ish) ISPs who espouse largely the same position. In fact, > any distinction between group A and group C is purely an academic > exercise as near as I can tell. > > On the other side of those who remember, we have group D. This > group is not ignorant of the limitations of the routing system. > We are not (yes, I consider myself a member of group D) unaware > of the issues with routing table growth in the current architecture. > However, we also remember that one of the primary goals for the > development of v6 was to FIX THIS. So far, it hasn't been fixed. > Between v4 and v6, really, nothing changed in terms of routing. > > However, for both v4 and v6, I am convinced that these issues > are far less urgent today, although I agree the problem has not > been completely solved. Fortunately, I think the problem _CAN_ > be solved and that we have approximately 10 years to solve it. > > Here's how I figure it: > > 1. The current routing table is comprised of just over 20,000 > active ASNs. The current v4 Prefix:ASN ratio is close to 8:1 > on average, with the peaks advertisers being several hundred > and the lows being 1. In the v6 world, this number should be > much much closer to 1:1, probably somewhere around 2:1 will > be realistic. That means that the current routing table > translated to a v6 world will shrink to less than 50,000 routes. > That should give us lots of headroom for v6 growth as v4 > becomes less and less prevalant and eventually is not > globally routed. > > 2. It is unlikely that the internet will see anywhere near the > explosive growth of the 90s in the next 5-10 years. Even if it > did, we would still stay well short of 160,000 v6 routes which > is well under most estimates I've heard for current hardware > capability. As such, there shouldn't be much of a problem > for at least 10 years. > > 3. The large(ish) ISPs comprise the majority of the operational > focus in the IETF, and, indeed have been a strong enough force > there that they were able to get RFCs cranked out which > attempted to preserve a completely provider-dependent > addressing model for the v6 internet. As such, faced with > building a scalable routing system or waiting for the network > to implode, I would hope that they will start working towards > a more scalable solution, such as ID/LOC splits. > > 4. I think that if IETF and large(ish) ISPs and router vendors > work towards a solution, 10 years is more than enough time for > development, testing, and, early deployment. > > 5. Vendor focus, in my experience, tends to be towards making > the large(ish) ISPs happy and the majority of enterprises > are a secondary consideration. This makes sense when you > consider that the average large(ish) ISP spends several > million dollars per year with their router vendor(s) of > choice, while the rest of the world is significantly less > per enterprise (in most cases) spread over a much wider > collection of sales representatives. In most sales-oriented > organizations (which as near as I can tell, all the hardware > vendors are today), the sales rep with the largest dollar > value tends to have the largest say in the feature priorities. > > > > What concerns me are three things: > > > > 1. Enterprise customer who want PI addresses or useful multi-homing, and > > don't care about the problems it creates for the large ISPs that carry > > full routes. (That's their problem.) > > > > In reality it is everyone's problem > > if they want to transit one of these ISPs, or use best path routing > > (carry full routes and not just a default to a transit provider). > > > > Lets not forget that router vendors are behind the curve on port speeds > > too. Are these vendors more likely to solve the routing table problem > > that affects only the largest ISPs or focus on port speed problems that > > affect many large enterprise customers? > > > Yes, in today's architecture, if we assume that this policy will double > the number of ASNs and that the advertising ratio for v6 does come out > close to 2:1, we'll see a v6 routing table, fully deployed, of about > 100,000 routes. That's still smaller than the current v4 table, and, > that's assuming that the number of ASNs issued doubles (which I think is > unlikely in the next 10 years). > > > 2. The concern people are being short sited and since there are only 1,000 > > routes in the IPv6 Internet table that this will not be a problem any time > > soon. > > > No... People supporting this policy aren't looking at 1,000 v6 routes and > saying "see... v6 table has lots of room". They're saying "Look: v6 is > failing to gain acceptance. Further, looking at the number of ASNs in > v4, we can extrapolate that v6 will have better aggregation per ASN, and, > thus we shouldn't see more than 2:1 prefix ratio in v6. That means that > the current v4 internet could be re-implemented in v6 with less than 50,000 > routes (vs. the current 180,000+)." I don't mind that you disagree with > our argument, but, please don't call us short-sighted or ignorant > using a different argument than the one we presented. > > > 3. The concern that we haven't done enough research to know if the vendors > > will be able to stay far enough ahead of the route table growth to not > > have a problem. It is not enough for vendors to build the routers big > > enough in time. If it takes 3 years to fully replace a network, and the > > router vendors are only two years ahead of the curve, then I only get 2/3 > > through my upgrades before having to start a new set of upgrades. Never > > mind being able to depreciate the cost of the router over 5 years. > > > I think it doesn't matter. ISPs will route what ISPs will route. Having > ARIN addressing policy protect ISPs from the legitimate demands of their > customers is an inappropriate use of policy in my opinion. ARIN should > neither encourage nor prohibit the routing of any prefix by any ISP. > That should be a contractual matter between the ISPs and their peers > and customers. > > Having said that, I also think that the only real way to address the > true needs of the community is by coming up with a scalable routing > solution. I do not believe that any routing solution based on using > the same number for end system identifier (ID) and topological > locator (LOC) can scale. I do think that there are possible advantages > to having some level of geographic distribution of these PI addresses > and I encourage the research and effort that is being done toward > that end at this time. However, I hope that IETF will see this > policy (and similar discussions starting to happen in other RIRs) > and start working on a viable long-term routing protocol so that we > can deploy it before this really becomes an issue. > > > We have to understand what it means to make a long term commitment to > > deaggregation. I don't hear the six largest ISPs standing up and saying > > we did some studies of what the routing table will look like in five to > > ten years, and have talked to our vendors and we don't think it will be a > > problem. > > > You're right. Instead, you hear a reasonable sampling of their customers > standing up and saying "We're not going to take this any more" about the > provider-lock-in based addressing of the CIDR world. > > > > The point Aaron was trying to make was in reference to my > > projections. For example I want to buy new routers today. It takes 2 > > years to certify and fully deploy the router throughout the network. I > > want the router to live in the network for 5 years to depreciate the > > value. That means if by 2011 there is wide spread adoption of IPv6 the > > router will need to support 1.3M routes. This example does not take into > > consideration L3VPN routes, or routes from converging multiple networks > > onto a single chassis. > > > Where on earth did you get the idea that there would be 650,000 active > ASNs by 2011? You're going to have to work real hard to show me > any reasonable projection that predicts such a value. > > If you're claiming that would be the sum of v4 and v6 routes, I would > argue that if v6 adoption is that wide by 2011, the majority of the > core would be v6 and v4 routes would become native only in local pockets. > Across the core, they would be v4 in v6 tunnels, so, the big 6 would > have alternatives to carrying both sets of routes in any one router. > Also if v6 adoption is that widespread, I think that the number of people > still using v4 would be significantly reduced if, for no other reason, > ISPs will start charging extra to preserve v4 infrastructure by then. > > Bottom line, I think your projections are simply unrealistic by any > === message truncated ===> _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From narten at us.ibm.com Thu Apr 27 14:40:54 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 27 Apr 2006 14:40:54 -0400 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal In-Reply-To: Message from "George Kuzmowycz" of "Tue, 25 Apr 2006 16:39:04 EDT." Message-ID: <200604271841.k3RIesT4008697@cichlid.raleigh.ibm.com> "George Kuzmowycz" writes: > David Williamson wrote on 04/25/2006 9:42:40 AM: > > Sounds like I better go read the draft. I agree that ownership > > rights would be a problem > Why is the (potential) ownership of IP addresses a Bad Thing? For public addresses that will be routed on the public internet, having them be "leased" rather than "owned" provides some amount of leverage (just how much is a matter of debate) against misbehavior. I.e., if an address holder wants to get more address space, but they haven't been playing by the rules, ARIN can say "but you aren't adhering to your agreement"... In more extreme cases, one can imagine ARIN producing a policy actually revoking the address space of abusers. But if address space is "owned", rather than "leased", no such leverage exists, presumably. Having said that, ULA space is different, precisely because it is not intended to be routed publically, so IMO it's much less clear that the same amount of leverage is needed/appropriate. Thomas From narten at us.ibm.com Thu Apr 27 15:01:31 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 27 Apr 2006 15:01:31 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: Message from "william(at)elan.net" of "Wed, 26 Apr 2006 11:59:09 PDT." Message-ID: <200604271901.k3RJ1VvT009165@cichlid.raleigh.ibm.com> > What exactly makes you think that documents done as part of the > discussions at NANOG/ARIN can not go through RFC publication > process? They can, but what _official_ blessing would they have? (And some sort of official blessing seems part of the point, so that it can justifiably be called a 'best current practice'.) I can recall no recent document from ARIN being republished as an RFC. I can think of no "NANOG" document being published as such. So, in theory, it can be done, in practice you'd have to figure out the process and logistics for doing so (if you wanted the document to actually be blessed by ARIN and/or NANOG in some formal sense). > Note: RFC-Editor is [supposed to be] independent from IETF and can > publish documents as individual submissions or you can bring > it as individual submission from another group into IETF if > you get Operations AD to sponsor it. And all such "independent" documents typically get stamped with a "truth in advertising" statement something along the lines of the following stamped on them: This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. See RFC 3932 for details. Thomas From narten at us.ibm.com Thu Apr 27 16:01:56 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 27 Apr 2006 16:01:56 -0400 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ] In-Reply-To: Message from David Williamson of "Tue, 25 Apr 2006 06:42:40 PDT." <20060425134240.GC16281@shell01.corp.tellme.com> Message-ID: <200604272001.k3RK1u7L010768@cichlid.raleigh.ibm.com> David Williamson writes: > I haven't read the IETF proposal, but I'm hoping that we can simply > link this hypothetical internal infrastructure allocation to holding an > AS. In that way, there's no ownership created, since you certainly > don't own an AS number. Is this true? In what sense is an AS number "leased" or "loaned"? Under what conditions can an AS number holder be forced to return an AS number? Do those that obtain ASNs enter into a formal agreement/contract with ARIN prior to obaining an ASN? Thomas From vaf at cisco.com Thu Apr 27 16:40:08 2006 From: vaf at cisco.com (Vince Fuller) Date: Thu, 27 Apr 2006 13:40:08 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <6D094C1352F436FB1E267BE1@odpwrbook.hq.netli.lan> References: <6D094C1352F436FB1E267BE1@odpwrbook.hq.netli.lan> Message-ID: <20060427204008.GA27846@vaf-lnx1.cisco.com> Once again, I will submit myself to the definition of insanity by trying again (and no doubt failing) to explain a little bit about Internet scaling. In fairness, it is difficult to comprehend the issues and complexities of large network scaling until one has worked first hand in a large network environment. > 2. It is unlikely that the internet will see anywhere near the > explosive growth of the 90s in the next 5-10 years. Even if > did, we would still stay well short of 160,000 v6 routes which > is well under most estimates I've heard for current hardware > capability. As such, there shouldn't be much of a problem > for at least 10 years. This "analysis" completely misses the point. IMHO, it is also simply wrong. Growth trends clearly show that the fraction of Internet sites which are multi homed and/or which engage in traffic engineering via more-specifics is on the rise. Expect this trend to accelerate as the Internet becomes more mission- critical for businesses of all sizes. A substantial fraction (20%? 50%? more?) of the number of worldwide businesses would be a good guess at the eventual number of multihomed sites. How many businesses today don't have mission-critical phone service? There is good reason to believe that Internet access will be just as important in the future, particularly if the vision of the "converged network" comes to pass (not that I'm drinking that kool-aide... but that is a separate conversation). Multi-homing will drive the creation of enormous global routing state if the expedient "provider independant space" approach is taken in favor of the more difficult task of fixing the architecture (and no, I do not believe that shim6 will be a viable alternative). Believe it or not, consumer Internet usage also continues to grow at a super-linear rate, thanks to the emergence of applications which appeal to mainstream users (for example, peer-to-peer file sharing). As traditional telephony and other services are moved to the packet network, this trend will accelerate. As I probably mentioned in an earlier message, exponential and polynomial growth curves often don't look very exciting during the shallow, early stage of growth, when small numbers mask what will become an impressive trend. > 3. The large(ish) ISPs comprise the majority of the operational > focus in the IETF, and, indeed have been a strong enough force > there that they were able to get RFCs cranked out which > attempted to preserve a completely provider-dependent > addressing model for the v6 internet. As such, faced with > building a scalable routing system or waiting for the network > to implode, I would hope that they will start working towards > a more scalable solution, such as ID/LOC splits. This statement belies a fundamental lack of understanding of the IETF and the history of operator participation over the past 10 to 15 years. During that period, the IETF has been almost completely devoid of operational focus, partly due to low operator participation (see below for why some operators feel alienated) and partly due to active bias against "evil greedy bastard" ISPs. The output of the IETF, most notably in ipv6's lack of a scalable routing and addressing architecture, reflects this. In that particular case, those with operational experience were greeted with outright hostility; as the political consensus-building process converged on ipv6-nee-SIP, some operators did speak up and say "this isn't going to work... you are ignoring the fundamental scaling problems in routing and addressing". They were told "too bad" and actively discouraged from participating. Meanwhile the ipv6 brain trust said, to paraphrase a "talking Barbie" doll of the 1970s, that "math [solving that problem] is hard, let's go shopping [design packet headers] instead". > 5. Vendor focus, in my experience, tends to be towards making > the large(ish) ISPs happy and the majority of enterprises > are a secondary consideration. This makes sense when you > consider that the average large(ish) ISP spends several > million dollars per year with their router vendor(s) of > choice, while the rest of the world is significantly less > per enterprise (in most cases) spread over a much wider > collection of sales representatives. In most sales-oriented > organizations (which as near as I can tell, all the hardware > vendors are today), the sales rep with the largest dollar > value tends to have the largest say in the feature priorities. This statement couldn't be more wrong. In fact, I had to read it several times to make sure that I had parsed it correctly. I would be very interested in understanding your operational experience, particularly as it pertains to large ISP networks. In my experience in working for regional, then national, then international ISP networks from 1988 until 2001, it was abundantly clear that equipment vendors viewed "that Internet stuff" as a small, sometimes-profitable but low margin sidelight to enterprise networking. This was true when token ring source-route bridging (remember that?) and IBM terminal emulation were implemented more quickly and more correctly than sorely needed ISP features like OSPF, IS-IS, or BGP. It remains true today. Fact: high-end ISP equipment has large development costs, is intrinsically expensive to build, sells in relatively low volume, and has specialized, difficult, and/or costly-to-build features that appeal to a very small egment of the overall vendor customer base. Fact: enterprise equipment, by contrast, has fewer, simpler features, far more customers, lower cost, and much higher margins. Fact: ISPs may spend millions on equipment but enterprise customers spend billions. These are American-English millions, with six trailing zeros, and American-English billions, with nine trailing zeros (I understand that the U.K.-English definitions may be different). Fact: both sales and gross profit attached to enterprise sales dwarf ISP sales by orders of magnitude. Conclusion: enterprise customers drive vendor development, sales, and all other priorities. This has been true since the years of Cisco, when HP, Cisco's first big customer, bought orders of magnitude more equipment and generated orders of magnitude more profit than all ISP sales combined. It used to be said that the best motivator for development of ISP features was a prediction that what ISPs are using today is what enterprise customers will be using in 3 years. That meant that ISPs typically got those features a year or two after they really needed them, but at least the eventually did get them. It isn't clear whether the next generation of cutting-edge ISP features will continue to "trickle down" to enterprise users; for ISP's sake, one would fervently hope that they do. This "conspiracy of the vendors and the big ISPs" has more in common with analysis of the Zapruder tape and theories about the grassy knoll than it does with business reality. It really is time to give it a rest already. --Vince (not in any way, shape, or form speaking for my current employer) From vaf at cisco.com Thu Apr 27 17:04:33 2006 From: vaf at cisco.com (Vince Fuller) Date: Thu, 27 Apr 2006 14:04:33 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <20060427204008.GA27846@vaf-lnx1.cisco.com> References: <6D094C1352F436FB1E267BE1@odpwrbook.hq.netli.lan> <20060427204008.GA27846@vaf-lnx1.cisco.com> Message-ID: <20060427210433.GA29073@vaf-lnx1.cisco.com> `g On Thu, Apr 27, 2006 at 01:40:08PM -0700, Vince Fuller wrote: P.S. lest this message, and in particular: > Conclusion: enterprise customers drive vendor development, sales, and all > other priorities. This has been true since the years of Cisco, when HP, > Cisco's first big customer, bought orders of magnitude more equipment and > generated orders of magnitude more profit than all ISP sales combined. > > It used to be said that the best motivator for development of ISP features > was a prediction that what ISPs are using today is what enterprise customers > will be using in 3 years. That meant that ISPs typically got those features > a year or two after they really needed them, but at least the eventually did > get them. It isn't clear whether the next generation of cutting-edge ISP > features will continue to "trickle down" to enterprise users; for ISP's sake, > one would fervently hope that they do. be mis-interpreted: I would strike the last sentence from the above as it does not reflect today's reality. The situation for ISPs is far better now than when I worked for a large Cisco (and other vendor) customer. ISPs are clearly an important part of Cisco's business and Cisco devotes enormous resources to serving its ISP customers and to developing features and products which those customers require. It remains the case, though, that the original posters statement: > 5. Vendor focus, in my experience, tends to be towards making > the large(ish) ISPs happy and the majority of enterprises > are a secondary consideration. This makes sense when you > consider that the average large(ish) ISP spends several > million dollars per year with their router vendor(s) of > choice, while the rest of the world is significantly less > per enterprise (in most cases) spread over a much wider > collection of sales representatives. In most sales-oriented > organizations (which as near as I can tell, all the hardware > vendors are today), the sales rep with the largest dollar > value tends to have the largest say in the feature priorities. incorrectly states that ISPs are the sole primary focus of development efforts to the exclusion or de-prioritization of enterprise customers. That simply isn't true. --Vince (still speaking only for myself and not for my employer) From marla_azinger at eli.net Thu Apr 27 17:21:21 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 27 Apr 2006 14:21:21 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D12@wava00s2ke2k01.corp.pvt> I concur with Jason's comments below. So it appears in order to push this forward it will require the creation of a "document" that is made carefully with input from ARIN/NANOG participants. Then the document hopefully having a positive consensus of support can be taken to IETF for possibly being published as a IETF blessed document. Also, Chris to your one comment: "Today, MOST providers will accept and re-advertise a /24 route, this > seems to be a 'globally agreed upon' boundary. This is good and bad > (debate later). In v6 this hasn't really been set yet, though with > 2005-1 passing (potentially, depending on AC I suppose?) the boundary > will be /48... it'll quickly be 'all /48' as well I predict." For V6 I have been asking around and it appears that almost all large transits if not all are filtering at the /32. If the PI Policy goes through then I believe ONLY the /48's and more specific that FALL WITHIN the "Set aside block by ARIN", will have filters opened up for them to go through. So if you dont receive an Allocation from the PI section, then you will still be filtered out at the /32. This is yet another reason why I am pushing for a document that supports more specifics to be routed so that we may use the technology that exists. Hopefully this would only be a short term solution. I would hope this would motivate the Shim 6 or 8+8 groups to work faster towards a solution for multihoming. Thank you Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jason Schiller (schiller at uu.net) Sent: Wednesday, April 26, 2006 8:57 PM To: Christopher Morrow Cc: ppml at arin.net Subject: Re: [ppml] "Recommended Practices" procedure Chris, Yes... and no So the problem is that each of the forums have the pros and cons... ITEF is global, but BCPs will have to continously be obsoleted, and not easily referenced. IETF maybe lacks enough operators support. ARIN seems to have a good consensus building forum, and has the IP address policy people. Routing policy seems intertwined with IP address policy. ARIN is not global, and would require some sort of Policy Resource Organization (PRO) to synchronize policy between RIRs. The OGs have more operators and may have more useful input on what the concerns about a given routing policy might be. The NOGs lack any support for publishing, or even consensus building, and is not global. Somehow a mixture of the three seems most optimal... ___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, 26 Apr 2006, Christopher Morrow wrote: > Date: Wed, 26 Apr 2006 23:14:15 -0400 > From: Christopher Morrow > To: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > On 4/25/06, Marshall Eubanks wrote: > > Well, I am not going to say that I disagree about that either, but > > it's pretty clear to me that there are interested people here who do > > not generally > > come to NANOGs or ARIN meetings. Of course, many of them don't come > > to IETF's either... > > is there not a reason to pursue it at both? The problem that Jason > (and I think Marla) are dancing around is that in an RIR based > solution, or any solution that is not 'globally agreed upon', lends > itself to a failed solution. > > Today, MOST providers will accept and re-advertise a /24 route, this > seems to be a 'globally agreed upon' boundary. This is good and bad > (debate later). In v6 this hasn't really been set yet, though with > 2005-1 passing (potentially, depending on AC I suppose?) the boundary > will be /48... it'll quickly be 'all /48' as well I predict. > > > On Apr 25, 2006, at 6:13 PM, Jason Schiller (schiller at uu.net) wrote: > > > > > Not that I dis-agree, but why not a BOF at the next NANOG? > > > > > > ___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, 25 Apr 2006, Marshall Eubanks wrote: > > > > > >> Date: Tue, 25 Apr 2006 18:08:43 -0400 > > >> From: Marshall Eubanks > > >> To: "Azinger, Marla" > > >> Cc: Thomas Narten , ppml at arin.net > > >> Subject: Re: [ppml] "Recommended Practices" procedure > > >> > > >> This issue had a big discussion about this at the RIPE-52 meeting now > > >> on-going in Istanbul, and I believe > > >> that a resolution similar to 2005-1 is likely to result from it. Are > > >> you going to ignore them and the other communities. > > >> > > >> I would suggest a BOF at the Montreal IETF. Here are the parameters > > >> for doing this : > > >> > > >> ----- > > >> -- Cut-off date for requesting a session: Monday, June 5 at 17:00 > > >> ET > > >> (21:00 > > >> UTC/GMT). > > >> -- Preliminary agenda published for comment: Friday, June 9 by > > >> midnight ET. > > >> -- Cut-off date for requests to reschedule a session: Wednesday, > > >> June > > >> 14 at > > >> 09:00 ET (13:00 UTC/GMT). > > >> -- Final schedule published: Monday, June 19 before midnight ET. > > >> > > >> Submitting Requests for Working Group and BOF Sessions > > >> > > >> Please submit requests to schedule your Working Group sessions using > > >> the "IETF > > >> Meeting Session Request Tool," a Web-based tool for submitting all of > > >> the > > >> information that the Secretariat requires to schedule your sessions. > > >> ----- > > >> > > >> Regards > > >> Marshall > > >> > > >> On Apr 25, 2006, at 5:47 PM, Azinger, Marla wrote: > > >> > > >>> Also, I feel as though ARIN/NANOG discussion and forum would lead > > >>> to a more balanced internet community solution. Keeping a document > > >>> that can reside in a specific "reachable" place would be nice. If > > >>> it were to reside as a Best business Practice Document with ARIN/ > > >>> NANOG then I feel the ability to "change" it when needed would also > > >>> be easier to accomplish. > > >>> > > >>> Marla > > >>> > > >>> -----Original Message----- > > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On > > >>> Behalf Of > > >>> Thomas Narten > > >>> Sent: Tuesday, April 25, 2006 2:17 PM > > >>> To: tony.li at tony.li > > >>> Cc: ppml at arin.net > > >>> Subject: Re: [ppml] "Recommended Practices" procedure > > >>> > > >>> > > >>> "Tony Li" writes: > > >>> > > >>>>> What I see frustrating here is that everyone agrees we need > > >>>>> some sort of "internet community agreement" that addresses V6 > > >>>>> routing. I hear alot of people asking for this, including > > >>>>> myself. Yet I dont hear any specific forum stepping forward > > >>>>> to help facilitate this need. > > >>> > > >>>> What you're asking for is a "routing and addressing architecture". > > >>>> Currently, it's really the purview of the IETF, except that they've > > >>>> basically abdicated the role. This creates a vacuum, which, as > > >>>> you note > > >>>> cries out to be filled. There are multiple ways to make progress > > >>>> here, > > >>>> but my favorite is for ARIN to simply push the problem back to the > > >>>> IETF > > >>>> and insist on a sensible and scalable solution. > > >>> > > >>> I think that what people want has a lot to do with operations and > > >>> operational practices, an area the IETF struggles with at times. > > >>> There > > >>> is v6ops WG in the IETF: > > >>> > > >>> http://www.ietf.org/html.charters/v6ops-charter.html > > >>> > > >>> Reading the charter, my takes is that what I think I'm hearing > > >>> people > > >>> calling for (best practices on things like route filters, is > > >>> deaggration allowed or not and under what conditions, etc., etc.) > > >>> would be in-scope there. > > >>> > > >>> Maybe it's time to approach that group (and the ADs), see if > > >>> there is > > >>> a willingness to take on such work in the IETF. What they will > > >>> want to > > >>> see is a critical mass of folk agreeing on the work that needs to be > > >>> done (i.e., what kind of document and what is in it) and assurance > > >>> that there are enough volunteers to do the actual work. Even if the > > >>> work is "officially" housed there, there is no reason why the work > > >>> couldn't also be discussed in the various RIR and operations > > >>> groups. > > >>> > > >>> I think the IETF would be as good a place as any to try and do this > > >>> work. (And I'm willing to help make this happen if people think > > >>> this > > >>> is worth pursuing.) > > >>> > > >>> Thomas > > >>> > > >>> _______________________________________________ > > >>> PPML mailing list > > >>> PPML at arin.net > > >>> http://lists.arin.net/mailman/listinfo/ppml > > >>> _______________________________________________ > > >>> PPML mailing list > > >>> PPML at arin.net > > >>> http://lists.arin.net/mailman/listinfo/ppml > > >> > > >> _______________________________________________ > > >> PPML mailing list > > >> PPML at arin.net > > >> http://lists.arin.net/mailman/listinfo/ppml > > >> > > > > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From jason.schiller at mci.com Thu Apr 27 17:45:25 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 27 Apr 2006 17:45:25 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <6D094C1352F436FB1E267BE1@odpwrbook.hq.netli.lan> Message-ID: On Thu, 27 Apr 2006, Owen DeLong wrote: > Date: Thu, 27 Apr 2006 01:03:08 -0700 > From: Owen DeLong > To: "Jason Schiller (schiller at uu.net)" , > Arin Archive > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 > > > On the other side of those who remember, we have group D. This > group is not ignorant of the limitations of the routing system. > We are not (yes, I consider myself a member of group D) unaware > of the issues with routing table growth in the current architecture. > However, we also remember that one of the primary goals for the > development of v6 was to FIX THIS. So far, it hasn't been fixed. > Between v4 and v6, really, nothing changed in terms of routing. > > However, for both v4 and v6, I am convinced that these issues > are far less urgent today, although I agree the problem has not > been completely solved. Fortunately, I think the problem _CAN_ > be solved and that we have approximately 10 years to solve it. IPv6 had as its goal to provide enough address space. It did that, but that also has implications on the global routing table. This is why it is suggested that there be an architectural approach to solving PI, multi-homing, and mobility problems that do not rely on de-aggregation. A solution with a complete locator/ID split would probably work, but the shim6 working group doesn't seem to want to indulge the traffic engineering needs or requirements of the service providers, content providers or large enterprise customers who beleive IPv6 traffic engineering should be at least as functional as IPv4 traffic engineering. Accepting this PI policy sends the signal that de-aggregation is an acceptable solution. Maybe people might think it is a good idea to allow PI /64s (or /48s) for cell phones into the global routing table to allow them to be mobile. > > Here's how I figure it: > > 1. The current routing table is comprised of just over 20,000 > active ASNs. The current v4 Prefix:ASN ratio is close to 8:1 > on average, with the peaks advertisers being several hundred > and the lows being 1. In the v6 world, this number should be > much much closer to 1:1, probably somewhere around 2:1 will > be realistic. That means that the current routing table > translated to a v6 world will shrink to less than 50,000 routes. > That should give us lots of headroom for v6 growth as v4 > becomes less and less prevalant and eventually is not > globally routed. It is very clear to me that people advertise more specific slices of their aggrgegate to do traffic engineering. Why do you think the number of extra more specific slices for traffic engineering will be reducted to 2:1? The way I see it by translating the IPv4 table into IPv6 you have the following. Start with the CIDR report: Recent Table History Date Prefixes CIDR Agg 03-03-06 179530 118693 AS Summary 21636 Number of ASes in routing system Divide the IPv4 table into three types of routes 1. Aggregates 2. De-aggergates that result from adding a second non-contigous block (these will go away with IPv6 as the initial assignment will be large) 3. De-aggergates that result from dividing an aggrgegate for traffic engineering Take the number of Internet routes and subtract the number of potentitial CIDR aggrgegates 179530 - 118693 = 60837 This is roughly the number of de-aggergates for traffic engineering. So the IPv4 Internet routing table is 179,530 The IPv6 Internet routing table is the number of IPv6 de-aggergates for traffic engineering + one aggregate per ASN. (This assumes that the same TE practices in IPv4 will be carried over to IPv6) 21636 + 60837 = 82473 Thats 179,530 IPv4 Internet routes + 82,473 IPv6 Internet routes -------------------------------- 262,003 IPv4/IPv6 Internet routes Add to that internal more specifics which for a large ISP is between 50,000 and 150,000. And add to that IPv6 internal more specifics say between 40,000 and 120,000. That somewhere between 352,003 and 532,003 routes assuing everyone does dual stack tomarrow. I know that there will be some ramp up period, but we need to understand what the routing table will look like once there is wide spread adoption... You can argue when wide spread adoptioin will happen, and project out IPv4 Internet growth, IPv4 de-aggergates for traffic engineering, and number of ASNs and get a reasonable number of what the IPv6 routing table will be given normal growth and solving multi-homing with more specifics in the same way as IPv4. So I don't think it is unreasonable to think on the agressive side that there might be fairly good adoption of IPv6 by 2013. My projections show 1.3M routes by 2013... That means if I want to upgrade a router now, and it takes 2 years to certify and fully replace my existing network and I want to depreciate the cost of the router over 5 years, then I need to buy routers that support 2.3M routes. The next question is translating number of routes into RIB size FIB size, CPU speed, etc... Geoff Hustom has done some studies in this area... Take a look at the slides from GROW at IETF 65: http://www3.ietf.org/proceedings/06mar/slides/grow-1.pdf http://www3.ietf.org/proceedings/06mar/slides/grow-0.pdf http://www3.ietf.org/proceedings/06mar/slides/grow-3.pdf My projections are covered in the middle link. > > 2. It is unlikely that the internet will see anywhere near the > explosive growth of the 90s in the next 5-10 years. Even if it > did, we would still stay well short of 160,000 v6 routes which > is well under most estimates I've heard for current hardware > capability. As such, there shouldn't be much of a problem > for at least 10 years. > > 3. The large(ish) ISPs comprise the majority of the operational > focus in the IETF, and, indeed have been a strong enough force > there that they were able to get RFCs cranked out which > attempted to preserve a completely provider-dependent > addressing model for the v6 internet. As such, faced with > building a scalable routing system or waiting for the network > to implode, I would hope that they will start working towards > a more scalable solution, such as ID/LOC splits. I don't think there is enough operator support in IETF. Clearly the operators don't carry that much wieght. We can't get shim6 to consider current operational traffic engineering preferences as a "requirement" > > 4. I think that if IETF and large(ish) ISPs and router vendors > work towards a solution, 10 years is more than enough time for > development, testing, and, early deployment. I need a solution 7 years ahead of the day routers start crashing. > > 5. Vendor focus, in my experience, tends to be towards making > the large(ish) ISPs happy and the majority of enterprises > are a secondary consideration. This makes sense when you > consider that the average large(ish) ISP spends several > million dollars per year with their router vendor(s) of > choice, while the rest of the world is significantly less > per enterprise (in most cases) spread over a much wider > collection of sales representatives. In most sales-oriented > organizations (which as near as I can tell, all the hardware > vendors are today), the sales rep with the largest dollar > value tends to have the largest say in the feature priorities. > When I raise this issue with vendors and ask if other ISPs are concered abot this they say that the question is very interesting, they have not beeing looking at the loing term impact of IPv6 on the routing table size and I am the first to provid some numbers of how big and by when. ___Jason From jason.schiller at mci.com Thu Apr 27 18:02:03 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 27 Apr 2006 18:02:03 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <036001c669f4$dd8119c0$56b3db18@ssprunk> Message-ID: On Thu, 27 Apr 2006, Stephen Sprunk wrote: > We'd prefer a better solution, really, but the IETF has failed to provide us > one. Since multihoming is a fundamental business requirement for > enterprises and PI is the only way to make multihoming work today, either > enterprises get PIv6 or v6 doesn't happen. > > Please keep in mind that we don't like this situation any more than you do. Yeah, we need an architectural solution. Maybe complete seperation of locator and ID??? > OTOH, one could say that large ISPs don't care about the problems that PA > space causes enterprises. 2005-1 is an attempt to find a compromise that's > acceptable to both sides. Large ISPs have been accused of liking the provider lock-in too... I personally am no in that camp. I think IPv6 needs an architectural approach to solving PI and and multi-homing. If we could completely seperate locator and ID with something like 8+8/GSE, have DNS only reflect the ID, and have the network map one or more routing goops to a site (Yes I know this needs some protocol), and use only the low order bits for TCP session termination and firewall filters. Then we have solved both the provider independant and multi-homing problem. > OTOH, I don't see any ISPs standing up and saying they did some studies of > what the routing table will look like in five to ten years, and have talked > to our vendors and we _do_ think it will be a problem. [sic] > http://www3.ietf.org/proceedings/06mar/slides/grow-1.pdf http://www3.ietf.org/proceedings/06mar/slides/grow-0.pdf http://www3.ietf.org/proceedings/06mar/slides/grow-3.pdf ___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. From jason.schiller at mci.com Thu Apr 27 18:07:58 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 27 Apr 2006 18:07:58 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D12@wava00s2ke2k01.corp.pvt> Message-ID: Marla, Currently we filter on the /32 boundry except for legacy /35s and critical infrastructure. I don't disagree with you about providers filtering on the /48 boundry for PI either. But I don't see how anyone can defend allowing PI multihomers 1 slot (/48) in the routing table, but not allowing PA multi-homers one slot (/48) in the routing table. Either de-aggregation is an acceptible solution to multi-homing, or it isn't. Whether the end-site uses a PI address or a PA address should make no difference. Secondly, when customers start to whine about wanting to slice up their announcement to the global routing table the boundry may slip a bit. ___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 Thu, 27 Apr 2006, Azinger, Marla wrote: > Date: Thu, 27 Apr 2006 14:21:21 -0700 > From: "Azinger, Marla" > To: "Jason Schiller (schiller at uu.net)" , > Christopher Morrow > Cc: ppml at arin.net > Subject: RE: [ppml] "Recommended Practices" procedure > > I concur with Jason's comments below. So it appears in order to push this forward it will require the creation of a "document" that is made carefully with input from ARIN/NANOG participants. Then the document hopefully having a positive consensus of support can be taken to IETF for possibly being published as a IETF blessed document. > > Also, Chris to your one comment: > "Today, MOST providers will accept and re-advertise a /24 route, this > > seems to be a 'globally agreed upon' boundary. This is good and bad > > (debate later). In v6 this hasn't really been set yet, though with > > 2005-1 passing (potentially, depending on AC I suppose?) the boundary > > will be /48... it'll quickly be 'all /48' as well I predict." > > For V6 I have been asking around and it appears that almost all large transits if not all are filtering at the /32. If the PI Policy goes through then I believe ONLY the /48's and more specific that FALL WITHIN the "Set aside block by ARIN", will have filters opened up for them to go through. So if you dont receive an Allocation from the PI section, then you will still be filtered out at the /32. > > This is yet another reason why I am pushing for a document that supports more specifics to be routed so that we may use the technology that exists. Hopefully this would only be a short term solution. I would hope this would motivate the Shim 6 or 8+8 groups to work faster towards a solution for multihoming. > > Thank you > Marla > > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Jason Schiller (schiller at uu.net) > Sent: Wednesday, April 26, 2006 8:57 PM > To: Christopher Morrow > Cc: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > > Chris, > > Yes... and no > > So the problem is that each of the forums have the pros and cons... ITEF > is global, but BCPs will have to continously be obsoleted, and not easily > referenced. IETF maybe lacks enough operators support. > > ARIN seems to have a good consensus building forum, and has the IP address > policy people. Routing policy seems intertwined with IP address > policy. ARIN is not global, and would require some sort of Policy > Resource Organization (PRO) to synchronize policy between RIRs. > > The OGs have more operators and may have more useful input on what the > concerns about a given routing policy might be. The NOGs lack any support > for publishing, or even consensus building, and is not global. > > Somehow a mixture of the three seems most optimal... > > ___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, 26 Apr 2006, Christopher Morrow wrote: > > > Date: Wed, 26 Apr 2006 23:14:15 -0400 > > From: Christopher Morrow > > To: ppml at arin.net > > Subject: Re: [ppml] "Recommended Practices" procedure > > > > On 4/25/06, Marshall Eubanks wrote: > > > Well, I am not going to say that I disagree about that either, but > > > it's pretty clear to me that there are interested people here who do > > > not generally > > > come to NANOGs or ARIN meetings. Of course, many of them don't come > > > to IETF's either... > > > > is there not a reason to pursue it at both? The problem that Jason > > (and I think Marla) are dancing around is that in an RIR based > > solution, or any solution that is not 'globally agreed upon', lends > > itself to a failed solution. > > > > Today, MOST providers will accept and re-advertise a /24 route, this > > seems to be a 'globally agreed upon' boundary. This is good and bad > > (debate later). In v6 this hasn't really been set yet, though with > > 2005-1 passing (potentially, depending on AC I suppose?) the boundary > > will be /48... it'll quickly be 'all /48' as well I predict. > > > > > On Apr 25, 2006, at 6:13 PM, Jason Schiller (schiller at uu.net) wrote: > > > > > > > Not that I dis-agree, but why not a BOF at the next NANOG? > > > > > > > > ___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, 25 Apr 2006, Marshall Eubanks wrote: > > > > > > > >> Date: Tue, 25 Apr 2006 18:08:43 -0400 > > > >> From: Marshall Eubanks > > > >> To: "Azinger, Marla" > > > >> Cc: Thomas Narten , ppml at arin.net > > > >> Subject: Re: [ppml] "Recommended Practices" procedure > > > >> > > > >> This issue had a big discussion about this at the RIPE-52 meeting now > > > >> on-going in Istanbul, and I believe > > > >> that a resolution similar to 2005-1 is likely to result from it. Are > > > >> you going to ignore them and the other communities. > > > >> > > > >> I would suggest a BOF at the Montreal IETF. Here are the parameters > > > >> for doing this : > > > >> > > > >> ----- > > > >> -- Cut-off date for requesting a session: Monday, June 5 at 17:00 > > > >> ET > > > >> (21:00 > > > >> UTC/GMT). > > > >> -- Preliminary agenda published for comment: Friday, June 9 by > > > >> midnight ET. > > > >> -- Cut-off date for requests to reschedule a session: Wednesday, > > > >> June > > > >> 14 at > > > >> 09:00 ET (13:00 UTC/GMT). > > > >> -- Final schedule published: Monday, June 19 before midnight ET. > > > >> > > > >> Submitting Requests for Working Group and BOF Sessions > > > >> > > > >> Please submit requests to schedule your Working Group sessions using > > > >> the "IETF > > > >> Meeting Session Request Tool," a Web-based tool for submitting all of > > > >> the > > > >> information that the Secretariat requires to schedule your sessions. > > > >> ----- > > > >> > > > >> Regards > > > >> Marshall > > > >> > > > >> On Apr 25, 2006, at 5:47 PM, Azinger, Marla wrote: > > > >> > > > >>> Also, I feel as though ARIN/NANOG discussion and forum would lead > > > >>> to a more balanced internet community solution. Keeping a document > > > >>> that can reside in a specific "reachable" place would be nice. If > > > >>> it were to reside as a Best business Practice Document with ARIN/ > > > >>> NANOG then I feel the ability to "change" it when needed would also > > > >>> be easier to accomplish. > > > >>> > > > >>> Marla > > > >>> > > > >>> -----Original Message----- > > > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On > > > >>> Behalf Of > > > >>> Thomas Narten > > > >>> Sent: Tuesday, April 25, 2006 2:17 PM > > > >>> To: tony.li at tony.li > > > >>> Cc: ppml at arin.net > > > >>> Subject: Re: [ppml] "Recommended Practices" procedure > > > >>> > > > >>> > > > >>> "Tony Li" writes: > > > >>> > > > >>>>> What I see frustrating here is that everyone agrees we need > > > >>>>> some sort of "internet community agreement" that addresses V6 > > > >>>>> routing. I hear alot of people asking for this, including > > > >>>>> myself. Yet I dont hear any specific forum stepping forward > > > >>>>> to help facilitate this need. > > > >>> > > > >>>> What you're asking for is a "routing and addressing architecture". > > > >>>> Currently, it's really the purview of the IETF, except that they've > > > >>>> basically abdicated the role. This creates a vacuum, which, as > > > >>>> you note > > > >>>> cries out to be filled. There are multiple ways to make progress > > > >>>> here, > > > >>>> but my favorite is for ARIN to simply push the problem back to the > > > >>>> IETF > > > >>>> and insist on a sensible and scalable solution. > > > >>> > > > >>> I think that what people want has a lot to do with operations and > > > >>> operational practices, an area the IETF struggles with at times. > > > >>> There > > > >>> is v6ops WG in the IETF: > > > >>> > > > >>> http://www.ietf.org/html.charters/v6ops-charter.html > > > >>> > > > >>> Reading the charter, my takes is that what I think I'm hearing > > > >>> people > > > >>> calling for (best practices on things like route filters, is > > > >>> deaggration allowed or not and under what conditions, etc., etc.) > > > >>> would be in-scope there. > > > >>> > > > >>> Maybe it's time to approach that group (and the ADs), see if > > > >>> there is > > > >>> a willingness to take on such work in the IETF. What they will > > > >>> want to > > > >>> see is a critical mass of folk agreeing on the work that needs to be > > > >>> done (i.e., what kind of document and what is in it) and assurance > > > >>> that there are enough volunteers to do the actual work. Even if the > > > >>> work is "officially" housed there, there is no reason why the work > > > >>> couldn't also be discussed in the various RIR and operations > > > >>> groups. > > > >>> > > > >>> I think the IETF would be as good a place as any to try and do this > > > >>> work. (And I'm willing to help make this happen if people think > > > >>> this > > > >>> is worth pursuing.) > > > >>> > > > >>> Thomas > > > >>> > > > >>> _______________________________________________ > > > >>> PPML mailing list > > > >>> PPML at arin.net > > > >>> http://lists.arin.net/mailman/listinfo/ppml > > > >>> _______________________________________________ > > > >>> PPML mailing list > > > >>> PPML at arin.net > > > >>> http://lists.arin.net/mailman/listinfo/ppml > > > >> > > > >> _______________________________________________ > > > >> PPML mailing list > > > >> PPML at arin.net > > > >> http://lists.arin.net/mailman/listinfo/ppml > > > >> > > > > > > > > > > _______________________________________________ > > > PPML mailing list > > > PPML at arin.net > > > http://lists.arin.net/mailman/listinfo/ppml > > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From michel at arneill-py.sacramento.ca.us Thu Apr 27 18:13:46 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 27 Apr 2006 15:13:46 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: > Marla Azinger wrote: > This is yet another reason why I am pushing for a document that > supports more specifics to be routed so that we may use the > technology that exists. Hopefully this would only be a short > term solution. I would hope this would motivate the Shim 6 or > 8+8 groups to work faster towards a solution for multihoming. As far as I know work on GSE (descendant of 8+8) has stopped in 1997. I stopped working on MHAP (unrelated but somehow similar) in 2003. Unless you have specific information that I am unaware of, as of today I don't see why anybody would resurrect either. > Jason Schiller wrote: > I think IPv6 needs an architectural approach to solving PI and and > multi-homing. If we could completely seperate locator and ID with > something like 8+8/GSE, have DNS only reflect the ID, and have the > network map one or more routing goops to a site (Yes I know this > needs some protocol), and use only the low order bits for TCP > session termination and firewall filters. Then we have solved both > the provider independant and multi-homing problem. The IETF has decided that shim6 was the way to go. Unless you suggest that ARIN (or someone else) gets in the business of designing protocols, I'm interested in knowing where you think you can find such an animal. Michel. From marla_azinger at eli.net Thu Apr 27 18:49:44 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 27 Apr 2006 15:49:44 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D13@wava00s2ke2k01.corp.pvt> Hi Michel- If work on 8+8 truly stopped completely and nobody is looking at it at all, then I'm curious why it still comes up in conversation as one of the possible fixes (given improvement). However, that said, I do hear Shim 6 mentioned much more and how this one might be the best chance at creating a solution. I don't believe that Shim 6 has been disbanded yet. I believe working on improving shim 6 or resurrecting others and improving them would be done because "some of us care" (I'm sure I can hear some laughter out there, but I care). I know its tiresome to keep discussing and work on, however I believe supporting both sides of the coin. One being we want to multihome and two being we need to keep the routing tables healthy. I'm an optimist Marla -----Original Message----- From: Michel Py [mailto:michel at arneill-py.sacramento.ca.us] Sent: Thursday, April 27, 2006 3:14 PM To: Azinger, Marla Cc: ppml at arin.net Subject: RE: [ppml] "Recommended Practices" procedure > Marla Azinger wrote: > This is yet another reason why I am pushing for a document that > supports more specifics to be routed so that we may use the > technology that exists. Hopefully this would only be a short > term solution. I would hope this would motivate the Shim 6 or > 8+8 groups to work faster towards a solution for multihoming. As far as I know work on GSE (descendant of 8+8) has stopped in 1997. I stopped working on MHAP (unrelated but somehow similar) in 2003. Unless you have specific information that I am unaware of, as of today I don't see why anybody would resurrect either. > Jason Schiller wrote: > I think IPv6 needs an architectural approach to solving PI and and > multi-homing. If we could completely seperate locator and ID with > something like 8+8/GSE, have DNS only reflect the ID, and have the > network map one or more routing goops to a site (Yes I know this > needs some protocol), and use only the low order bits for TCP > session termination and firewall filters. Then we have solved both > the provider independant and multi-homing problem. The IETF has decided that shim6 was the way to go. Unless you suggest that ARIN (or someone else) gets in the business of designing protocols, I'm interested in knowing where you think you can find such an animal. Michel. From owen at delong.com Thu Apr 27 19:05:32 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Apr 2006 16:05:32 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <20060427204008.GA27846@vaf-lnx1.cisco.com> References: <6D094C1352F436FB1E267BE1@odpwrbook.hq.netli.lan> <20060427204008.GA27846@vaf-lnx1.cisco.com> Message-ID: <3A02C1143E9D0776AB33C183@imac-en0.delong.sj.ca.us> [Apologies to those on the list that feel I have exceeded my posting limit for the day. I could not let this stand without response.] My operational experience includes senior backbone engineering at a number of different ISPs, ranging from Netcom (mid-size, national at the time) to ConXioN (small start-up at the time) to Exodus (mid-size, national when I started and large international for a significant portion of the time I was there). I also have substantial enterprise and small business experience. I consult for several hosting providers today, as well as running the network for my current employer (mid-size, international). I agree that the IETF lacks operational focus. However, it is the large ISPs and router vendors that shouted loudest to avoid PI space, and, these are the groups that continue to shout the loudest. That is simply a fact. I agree that the operators, large ISPs, included were shouted down when they asked for scalable routing solutions. I don't know why the vendors in the room pushed so hard to avoid this topic, but, since you work for a vendor, perhaps you can answer that question. I'm not saying that there's any sort of conspiracy between vendors and large ISPs. I'm saying that vendors are over-represented in the IETF, large operators are underrepresented, and, enterprise and smaller consumers are virtually un-represented. Note, I consider ISVs as well as router vendors in the vendor category, so, Microsoft and their ilk are in with Cisco and their ilk in terms of my view of the demographics. I don't think that the IETF acted in bad faith, and, I'm not trying to make any such accusation. I do think that the IETF failed to deliver a scalable routing solution and continues to focus on dead-end paths that do not offer any possibility of real solution. Further, I do think that the large ISPs have a profit motive to preserve a PA only addressing model, and, that vendors have some benefit as well (although this is less clear). However, I had no intention or perspective that this was, in any way, any form of conspiracy between them, and, I apologize if I gave that impression. Nonetheless, from where I sit, two things are true... If we don't have PI space in v6, we won't have v6, and, nobody has proposed a scalable routing solution which does not involve id/locator split. Once they are split, the existence of PI is irrelevant to any scaling issue. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Apr 27 19:41:32 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Apr 2006 16:41:32 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: <347E139FEB7F12D5F16760A6@imac-en0.delong.sj.ca.us> --On April 27, 2006 6:07:58 PM -0400 "Jason Schiller (schiller at uu.net)" wrote: > Marla, > > Currently we filter on the /32 boundry except for legacy /35s and critical > infrastructure. > > I don't disagree with you about providers filtering on the /48 boundry for > PI either. > > But I don't see how anyone can defend allowing PI multihomers 1 slot > (/48) in the routing table, but not allowing PA multi-homers one slot > (/48) in the routing table. > > Either de-aggregation is an acceptible solution to multi-homing, or it > isn't. Whether the end-site uses a PI address or a PA address should make > no difference. > Deaggregation within a known prefix where it is widely known and accepted that some providers may not accept these prefixes because they are deaggregated is, in my opinion, preferable to a wild-west of deaggregates spread all over the addressing space. > Secondly, when customers start to whine about wanting to slice up their > announcement to the global routing table the boundry may slip a bit. > That will be up to the ISPs that accept or do not accept their routes. ARIN cannot and does not pretend to control this. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From vaf at cisco.com Thu Apr 27 20:27:28 2006 From: vaf at cisco.com (Vince Fuller) Date: Thu, 27 Apr 2006 17:27:28 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <3A02C1143E9D0776AB33C183@imac-en0.delong.sj.ca.us> References: <6D094C1352F436FB1E267BE1@odpwrbook.hq.netli.lan> <20060427204008.GA27846@vaf-lnx1.cisco.com> <3A02C1143E9D0776AB33C183@imac-en0.delong.sj.ca.us> Message-ID: <20060428002728.GA356@vaf-lnx1.cisco.com> > [Apologies to those on the list that feel I have exceeded my posting limit > for the day. I could not let this stand without response.] As I could not. But I plan this to be my last posting on this topic as either I will have pursuaded others to more clearly consider the big issues here or I won't by now. >> I ask myself "oh why do I waste keystrokes on this?" but then I do it >> anyway. If it is true that one definition of insanity is doing the same >> thing over and over while expecting the same result, then I should really >> stop trying to provide intelligent explainations about scaling issues on >> NANOG... >> > I believe you mean expecting different results. Indeed. That's what I get for posting to ppml or nanog under the influence of six days' cumulative sleep deprivation caused by a 10-hour jetlag... Interesting that the mind's ability to use context to see what it expects to see rendered useless any proof-reading of this paragraph. > My operational experience includes senior backbone engineering at a > number of different ISPs, ranging from Netcom (mid-size, national at the > time) to ConXioN (small start-up at the time) to Exodus (mid-size, national > when I started and large international for a significant portion of the > time I was there). I also have substantial enterprise and small business Interesting. Where you at Exodus during the "great GTEI-Exodus de-peering incident"? It contained an excellent anecdote on the subtlety of grasping large network scaling issues. At the risk of a little digression and reveleation of a tiny bit of confidential information that two companies that no longer exist can't really care about any more... Back in the 90s, GTEI was one of the top-tier "backbone" ISPs. Exodus, principally a hosting company, wanted settlement-free "private peering" and GTEI said no based on measurements that showed that Exodus sent far more traffic to GTEI than the reverse. This was one of the early uses of traffic ratios to call for settlements; the rationale was that traffic exchange via "shortest exit" caused the receiver of the traffic to bear a much larger share of the cost than the sender so when traffic was severely out of balance, a settlement was in order (the debate over this continues to this day and is one of the underlying *technical* rather than policy/anti-competitve around to "net neutrality"). Anyway, Exodus proposed that instead of paying a settlement, it instead do "best exit" (sometimes called "cold potato" routing) toward GTEI. GTEI technical staff initially rejected this because the only way to implement this in the routing system is to de-aggregate and send MEDs, which is fundamentally non-scalable. Management types overruled these objections and insisted that an experiment be tried, limiting the routing scope of the more-specifics by marking them "no export" to address the concern of non-scalability. Technical staff raised an additional concern that doing this created inconsistancies in the routing system which could only lead to bad things happening, but the experiment was tried anyway. What happened? Within a day of implementation, these concerns proved well- founded: more-specifics leaked and Exodus became a transit path for some high-profile GTEI customers. Needless to say, the experiment was quickly terminated. Again, I offer this description not to imply any incompetence or malfeasance on the part of any of the parties involved... just to show that it is very difficult to understand and appreciate big network scaling issues. > I don't think that the IETF acted in bad faith, and, I'm not trying to make > any such accusation. I do think that the IETF failed to deliver a scalable > routing solution and continues to focus on dead-end paths that do not > offer any possibility of real solution. Not bad faith but egos and expedience got in the way of hard problem solving. We can't afford for that mistake to go un-corrected. Oh well. My last post. Time to sit on planes for 20+ hours. --Vince From randy at psg.com Fri Apr 28 03:07:12 2006 From: randy at psg.com (Randy Bush) Date: Fri, 28 Apr 2006 10:07:12 +0300 Subject: [ppml] "Recommended Practices" procedure References: <200604271901.k3RJ1VvT009165@cichlid.raleigh.ibm.com> Message-ID: <17489.48928.650738.287823@roam.psg.com> > They can, but what _official_ blessing would they have? (And some sort > of official blessing seems part of the point, so that it can > justifiably be called a 'best current practice'.) this is an ops community, best current practice is defind by actual practice, not documents that often have never even been tested in practice randy From michel at arneill-py.sacramento.ca.us Fri Apr 28 03:26:33 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 28 Apr 2006 00:26:33 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: > Marla Azinger wrote: > If work on 8+8 truly stopped completely and nobody is looking > at it at all, then I'm curious why it still comes up in > conversation as one of the possible fixes (given improvement). A mix of "maybe I should not had given up on it", "I told you so" and "if only you had listened to what I said or read what I wrote 5 years ago". > However, that said, I do hear Shim 6 mentioned much more and > how this one might be the best chance at creating a solution. Because it's the official line of the party. The very fact that 2005-1 is going to last call is the official failure notice of shim6. > I don't believe that Shim 6 has been disbanded yet. It won't anytime soon. Utopias live forever. > I believe working on improving shim 6 or resurrecting others > and improving them would be done because "some of us care" > (I'm sure I can hear some laughter out there, but I care). That's what I believed when I started ipv6mh in early 2002. multi6 was virtually dead, and many people have told me privately that the only thing ipv6mh ever achieved was to maintain the illusion of a workable IPv6 multihoming solution. In other words, if I just had let multi6 die in 2002 we would not have wasted 4 more years for someone to put on the table a PI policy. > however I believe supporting both sides of the coin. One > being we want to multihome and two being we need to keep > the routing tables healthy. A lot of very bright people, many of them with the right political connections have tried for more than 10 years. All have failed; as the self-appointed curator of the failed IPv6 multihoming solutions museum, I can tell you that there's a lot on display already and I still could dig a few skeletons out of the closet. > I'm an optimist The time when IPv6 could be deployed with optimism has come and gone. > Owen DeLong wrote: > I agree that the IETF lacks operational focus. However, it is > the large ISPs and router vendors that shouted loudest to avoid > PI space, and, these are the groups that continue to shout the > loudest. That is simply a fact. Ack. > I'm not saying that there's any sort of conspiracy between vendors > and largeISPs. I'm saying that vendors are over-represented in the > IETF, large operators are underrepresented, and, enterprise and > smaller consumers are virtually un-represented. Another over-represented group is the academia. > I don't think that the IETF acted in bad faith, and, I'm not > trying to make any such accusation. I do think that the IETF > failed to deliver a scalable routing solution and continues > to focus on dead-end paths that do not offer any possibility > of real solution. Ack this too. > Further, I do think that the large ISPs have a profit > motive to preserve a PA only addressing model Of course they have. Customer lock-in. The fact of the matter is that PA-only is good for large, already established ISPs (which happens to be the ones with lobbying dollars to stuff IETF and ARIN meetings) while smaller ISPs trying to get in would likely favor policies that let them compete on service. I found a rather interesting correlation between ISP size and their support of or opposition to 2005-1, actually :-D Michel. From Michael.Dillon at btradianz.com Fri Apr 28 05:04:01 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 28 Apr 2006 10:04:01 +0100 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <20060427161819.GA23742@vaf-lnx1.cisco.com> Message-ID: > No, you are completely missing the point. Establishing a policy that > defines "provider independent space" sets a precedent that, for all > practical purposes, will not be revokable. Precisely my point. The precedent of PI address space was set long ago in IPv4 policy. It is not revokable. We have no choice but to put in place a reasonable PI policy for IPv6, monitor its effects, and adjust it if and when necessary. In addition, the legal and business climate in the ARIN region sets its own sort of precedent. It is not acceptable for ARIN to restrain trade. It is not acceptable for ARIN to establish a monopoly of ISPs controlling the IPv6 address space. > those recipients of a valuable commodity will not be easily persuaded to > give it up They will if an open and publicly created policy tells them to do so. Of course, such a policy is likely to also provide an alternative so it will be more of a migration than a "giving up". The concept of geo-topological aggregation is one way that could provide a future release valve for the pressures of PI demand. And if we assume that one eighth of the IPv6 space is given over to geo-topo addressing that still leaves six eighths (75%) of the IPv6 for 6 other addressing/routing schemes. > Those assignhments will be > permanent, just as all SRI-NIC-era assignments ("the swamp space") are > still filling the IPv4 routing table more than 10 years after they were > last granted. SRI-NIC assignees did not sign a registration services agreement. This is a false analogy. > And the hundreds of thousands of routes that are of concern to those who > think about "big Internet" scaling problems are what we *will* see if a > "PI space" policy is adopted. This statement, like most of your message, is filled with linear thinking. You assume that the future is going to be just like the past, only moreso. But history shows that it doesn't work that way. The Internet WILL NOT GROW AT ALL unless business and society grows its usage of the Internet. Historically, this type of growth results in quantitative changes. Compare 1930's radio with today's radio. There are many more radio stations today and vastly more radio listeners. But modern radio is a very different beast from 1930's radio. The same thing can be said about the growth of automobile usage. Who could have imagined high-rise parking garages in 1920? The biggest danger for ARIN is to have a failure of the imagination. The Internet does not change in a linear fashion and the future is not like a bigger form of the past. Look at the SPAM problem and how it has changed email usage compared with 1994. Look at how widespread private peering has wiped out the Internet exchange scaling problems that were foreseen in 1994. > Some organizations were good enough to transition off of pre-RIR IPv4 > assignments (anybody remember net 36.0.0.0) because of a sense of community > and of doing good for the collective; that sense of community has long since > vanished from the commercial Internet, so past behavior is most certainly > not a good indicator of future behavior. Again we agree. The past is not a good way to predict the future. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 28 05:12:26 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 28 Apr 2006 10:12:26 +0100 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <200604271901.k3RJ1VvT009165@cichlid.raleigh.ibm.com> Message-ID: > > What exactly makes you think that documents done as part of the > > discussions at NANOG/ARIN can not go through RFC publication > > process? > > They can, but what _official_ blessing would they have? (And some sort > of official blessing seems part of the point, so that it can > justifiably be called a 'best current practice'.) It is totally irrelevant whether or not a routing practices document is published in or out of the IETF. No such document will have "official blessing" unless it has been developed by a consensus of network operators. Once that has been reached, it is official BECAUSE OF THAT CONSENSUS. Whether vendors and researchers agree with this or not is totally irrelevant. We are talking about operational and business practices of network operators. These companies know enough about the economics of IP network operations to be able to assess a COST for the use of a global routing table slot. If they can agree on this cost and agree on routing practices, then there is the possibility of charging for use of global routing table slots. If record companies can find an acceptable way to account for the playing of music on the radio, then network operators should be able to solve the global routing table issue. But the first step is to come up with a reasonable framework within which the operators can discuss this issue and build a consensus. I think that ARIN is a reasonable organization to host this process. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 28 05:26:50 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 28 Apr 2006 10:26:50 +0100 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: Message-ID: > So I don't think it is unreasonable to think on the agressive side that > there might be fairly good adoption of IPv6 by 2013. My projections show > 1.3M routes by 2013... The unreasonableness is that you are thinking on the agressive side looking at worst cases. However, you are not allowing for the fact that remedial actions can be taken during the 7 year period leading to 2013. Nor are you recognizing that the economy does not grow linearly but in fits and starts. There is likely to be another downturn like the dotcom crash or the Asian flu (economic crash in 1997). In fact, it may indeed be caused by an epidemic of an Asian flue virus. So your argument boils down to saying that there is a POSSIBILITY that bad things will happen in 7 years if we pass this policy and then DO NOTHING from now on. I simply cannot imagine any way for ARIN to stop making policy changes from now on, therefore I find your argument very weak. I would love to see some real numbers where there is an attempt to look at best case, worst case and most likely case, because then I can make my own judgements about what to do in order to track the best case numbers rather than the worst case ones. --Michael Dillon From william at elan.net Fri Apr 28 08:43:04 2006 From: william at elan.net (william(at)elan.net) Date: Fri, 28 Apr 2006 05:43:04 -0700 (PDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: On Thu, 27 Apr 2006, Jason Schiller (schiller at uu.net) wrote: > Marla, > > Currently we filter on the /32 boundry except for legacy /35s and critical > infrastructure. > > I don't disagree with you about providers filtering on the /48 boundry for > PI either. > > But I don't see how anyone can defend allowing PI multihomers 1 slot > (/48) in the routing table, but not allowing PA multi-homers one slot > (/48) in the routing table. You can't defend that. You have to allow anybody who can multihome (i.e. have ASN) a slot in the routing table - after all why else do they have an ASN? [Note: I'm being slightly cynical, of course I know that ASNs are used for certain other routing setups too, but those are small in number] Of course the question for IETF now is not about that but they want to redefine what it means to multihome in the first place. > Either de-aggregation is an acceptible solution to multi-homing, or it > isn't. Whether the end-site uses a PI address or a PA address should make > no difference. My view is that right design would make 0 difference what local addresses are used by the site/network at all and not expose that to the world. But we seem to have missed that train .. or maybe not? > Secondly, when customers start to whine about wanting to slice up their > announcement to the global routing table the boundry may slip a bit. They have an announcement and its not in global routing table? No wonder they "whine"! :) -- William Leibzon Elan Networks william at elan.net From tme at multicasttech.com Fri Apr 28 09:14:44 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 28 Apr 2006 09:14:44 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: References: Message-ID: Dear Jason; Thank you for this information. I have been coming at this from the other direction (I, also, have been flying a lot this week!), let's see if the lines cross somewhere. On Apr 27, 2006, at 5:45 PM, Jason Schiller (schiller at uu.net) wrote: > On Thu, 27 Apr 2006, Owen DeLong wrote: > >> Date: Thu, 27 Apr 2006 01:03:08 -0700 >> From: Owen DeLong >> To: "Jason Schiller (schiller at uu.net)" , >> Arin Archive >> Cc: ppml at arin.net >> Subject: Re: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 >> >> >> On the other side of those who remember, we have group D. This >> group is not ignorant of the limitations of the routing system. >> We are not (yes, I consider myself a member of group D) unaware >> of the issues with routing table growth in the current architecture. >> However, we also remember that one of the primary goals for the >> development of v6 was to FIX THIS. So far, it hasn't been fixed. >> Between v4 and v6, really, nothing changed in terms of routing. >> >> However, for both v4 and v6, I am convinced that these issues >> are far less urgent today, although I agree the problem has not >> been completely solved. Fortunately, I think the problem _CAN_ >> be solved and that we have approximately 10 years to solve it. > > IPv6 had as its goal to provide enough address space. It did that, > but > that also has implications on the global routing table. This is > why it is > suggested that there be an architectural approach to solving PI, > multi-homing, and mobility problems that do not rely on de- > aggregation. > > A solution with a complete locator/ID split would probably work, > but the > shim6 working group doesn't seem to want to indulge the traffic > engineering needs or requirements of the service providers, content > providers or large enterprise customers who beleive IPv6 traffic > engineering should be at least as functional as IPv4 traffic > engineering. > > Accepting this PI policy sends the signal that de-aggregation is an > acceptable solution. Maybe people might think it is a good idea to > allow > PI /64s (or /48s) for cell phones into the global routing table to > allow them to be mobile. > >> >> Here's how I figure it: >> >> 1. The current routing table is comprised of just over 20,000 >> active ASNs. The current v4 Prefix:ASN ratio is close to 8:1 >> on average, with the peaks advertisers being several hundred >> and the lows being 1. In the v6 world, this number should be >> much much closer to 1:1, probably somewhere around 2:1 will >> be realistic. That means that the current routing table >> translated to a v6 world will shrink to less than 50,000 routes. >> That should give us lots of headroom for v6 growth as v4 >> becomes less and less prevalant and eventually is not >> globally routed. > > It is very clear to me that people advertise more specific slices > of their > aggrgegate to do traffic engineering. Why do you think the number of > extra more specific slices for traffic engineering will be reducted to > 2:1? > > The way I see it by translating the IPv4 table into IPv6 you have the > following. Start with the CIDR report: > Recent Table History > Date Prefixes CIDR Agg > 03-03-06 179530 118693 > AS Summary > 21636 Number of ASes in routing system > > Divide the IPv4 table into three types of routes > 1. Aggregates > 2. De-aggergates that result from adding a second non-contigous block > (these will go away with IPv6 as the initial assignment will be > large) > 3. De-aggergates that result from dividing an aggrgegate for traffic > engineering It is apparent to me that some multiple address blocks represent hidden autonomous systems. I have had several enterprise network architects tell me things along the line of "we have N address blocks, one for each location where we have a presence, and they have separate upstream providers, but we just don't feel like getting / paying for an ASN for each one of these". These clearly will not be aggregated; it is not clear to me how many CIDR aggregates fall into this class, but I suspect some do. > > Take the number of Internet routes and subtract the number of > potentitial > CIDR aggrgegates 179530 - 118693 = 60837 This is roughly the > number of > de-aggergates for traffic engineering. > Don't almost all of these fall in category 3 ? In addition, won't NONE of the category 2's (the address blocks are not contiguous, after all) be potential CIDR aggregates ? So it's not clear to me how good an estimate this is. In the spirit of back of the envelope estimates for years into the future, I will buy it, but we might be able to a better job defragmenting the address space. > So the IPv4 Internet routing table is 179,530 > > The IPv6 Internet routing table is the number of IPv6 de-aggergates > for > traffic engineering + one aggregate per ASN. (This assumes that > the same > TE practices in IPv4 will be carried over to IPv6) 21636 + 60837 = > 82473 > > Thats 179,530 IPv4 Internet routes > + 82,473 IPv6 Internet routes > -------------------------------- > 262,003 IPv4/IPv6 Internet routes > > Add to that internal more specifics which for a large ISP is between > 50,000 and 150,000. And add to that IPv6 internal more specifics say > between 40,000 and 120,000. That somewhere between 352,003 and > 532,003 > routes assuing everyone does dual stack tomarrow. > > I know that there will be some ramp up period, but we need to > understand > what the routing table will look like once there is wide spread > adoption... You can argue when wide spread adoptioin will happen, and > project out IPv4 Internet growth, IPv4 de-aggergates for traffic > engineering, and number of ASNs and get a reasonable number of what > the > IPv6 routing table will be given normal growth and solving multi- > homing > with more specifics in the same way as IPv4. > > So I don't think it is unreasonable to think on the agressive side > that > there might be fairly good adoption of IPv6 by 2013. My > projections show > 1.3M routes by 2013... That means if I want to upgrade a router > now, and > it takes 2 years to certify and fully replace my existing network > and I > want to depreciate the cost of the router over 5 years, then I need > to buy > routers that support 2.3M routes. Isn't this a typo, shouldn't it be "1.3M routes" ? Otherwise, I don't see where it comes from. I actually think that these numbers are not too far out of line; the question is, is the time line out of line ? The US Small Business Administration http://www.sba.gov/advo/research/us_03ss.pdf estimates that there were 5,696,600 employer firms in 2003, 99.7 percent of which are small firms (i.e., there are 17090 non small firms, with 500 or more employees). Of the employer firms, there are 2,262,695 with 5 or more employees, and 1,237,198 with 10 or more employees. I think that a reasonable upper bound for the potential number of ASNs in the US right now is the latter number. (Since the number of firms is not increasing exponentially as fast as routes are, and since I am resolutely in back of the envelope mode, I will assume that these numbers will be constant over the next decade.) Assume that the existing 182,282 routes that I see this afternoon are all due to large businesses, and that these can be aggregated to 82,473 routes, as your numbers suggest. This would suggest that the US might add (1,237,198 - 82,473 =) 1,154,725 routes eventually. Since the US is roughly 1/5 of the global economy, that suggests that the total number of additional routes might be as large as 6 million. The real question is, by when ? I get a doubling time in the number of route of ~ 6.5 years from my data. I do not see a formal doubling time estimate in your presentation, but you must have estimated it or the equivalent, to get your power law projections, so I would be curious to hear what it is. I don't see it as being too much different from your graphs. 182,000 to 6 million routes is 5.0 doublings, which means that I would predict that the system would saturate (without artificial constraints) in 33 years, and would reach 1 million routes in about 2.46 doublings, or ~ 16 years, or 2022. If you assume a doubling time of 5 years (which is not supported by the data, but let's assume things speed up to be conservative), we get saturation in 20 years, and 1 million routes in 12.3 years, or 2018. Note that if you can get a factor of 2 now by defragmenting the address space, that adds 1 doubling time (~ 6 years or more) to all of these estimates. Note also that you are assuming that most routes are doubled in v4 and v6, so that costs you a doubling time if there is no defragmentation. Let's assume that that is true, and that there is no defragmentation (to be conservative), I get and 1 million routes in 9.5 years, or late 2016. If (more reasonably, and more in line with your estimates), you assume a 50 % defragmentation of the IPv6 address space, and otherwise a sharing of space between v4 and v6 (i.e., assuming that every path is represented in both address spaces), then you get an address space predictor of (1.5 x 2^(# doublings)), or 1 million routes in 1.87 doubling times, or 12 years. (Hopefully IPv4 growth would actually start to slow at some point in this future, so I regard this as a pretty conservative estimate.) So, I would estimate that 1 million external routes (with no artificial constraints) should be achieved somewhere in the 2016 to 2022 time frame, and saturation somewhere around 2030 to 2040. (For saturation, you clearly also have to include an estimate of global economic growth in the next few decades, which would take us way off into the weeds.) Of course, I understand from your presentation that you get that number by including internal routes, so let's look at them too. > > The next question is translating number of routes into RIB size FIB > size, > CPU speed, etc... Geoff Hustom has done some studies in this area... > > Take a look at the slides from GROW at IETF 65: > > http://www3.ietf.org/proceedings/06mar/slides/grow-1.pdf > http://www3.ietf.org/proceedings/06mar/slides/grow-0.pdf > http://www3.ietf.org/proceedings/06mar/slides/grow-3.pdf > > My projections are covered in the middle link. > OK, 2013 is 7 years from now, so let's look at your 7 year predictions. For ease of discussion, I will reproduce these here, rounded off : IPv4 routes : 338,000 IPv4 intentional deaggregates : 195,000 Projected IPv6 : 237,000 Projected internal IPv4 (low) : 49,000 Projected internal IPv4 (high): 360,000 Projected internal IPv6 (low) : 132,000 Projected internal IPv6 (high): 404,000 Total External : 770,000 ( 31 % are IPv6) Total Internal (low) : 181,000 Total Internal (high) : 764,000 Totals (low) : 825,000 ( 29 % are IPv6 external) Totals (high) : 1,049,000 ( 23 % are IPv6 external) (Seven years is just a little over one doubling time from the present; I would predict a total of 576,000 v4 + v6 external routes then, so in back of the envelope mode I could buy 770,000.) So, for the 1.3 million route router you need to buy now, if SHIM6 was working today, and there were NO IPv6 routes required at all (ok, 1), then you would need to buy a 893,000 route router just to support IPv4. If you want to support IPv4 plus IPv6 (internal only), that's 1.2 million routes. So, I do not see that external IPv6 routing policy is driving your router purchases in the 7 year time horizon. Please correct me if I am wrong. Also, aren't internal routes something you have some control over ? I.e., isn't this something that you are paid to do, so if they are too expensive to support you can raise your prices, encourage aggregation, sub-divide your network, etc. ? Note, by the way, that even the most aggressive SHIM6 proponents don't predict its world domination in less than 7 years, so it's not likely to help much here. So, as a small multi-homer, I do not see a need to support 1.3 million routes in 7 years, but I do see a need to support 500,000 to 800,000, which may not be that different in practice. What I frankly do not see in all of these numbers is a reason not to support 2005-1. Regards Marshall >> >> 2. It is unlikely that the internet will see anywhere near the >> explosive growth of the 90s in the next 5-10 years. Even if it >> did, we would still stay well short of 160,000 v6 routes which >> is well under most estimates I've heard for current hardware >> capability. As such, there shouldn't be much of a problem >> for at least 10 years. >> >> 3. The large(ish) ISPs comprise the majority of the operational >> focus in the IETF, and, indeed have been a strong enough force >> there that they were able to get RFCs cranked out which >> attempted to preserve a completely provider-dependent >> addressing model for the v6 internet. As such, faced with >> building a scalable routing system or waiting for the network >> to implode, I would hope that they will start working towards >> a more scalable solution, such as ID/LOC splits. > > I don't think there is enough operator support in IETF. Clearly the > operators don't carry that much wieght. We can't get shim6 to > consider > current operational traffic engineering preferences as a "requirement" > > >> >> 4. I think that if IETF and large(ish) ISPs and router vendors >> work towards a solution, 10 years is more than enough time for >> development, testing, and, early deployment. > > I need a solution 7 years ahead of the day routers start crashing. > >> >> 5. Vendor focus, in my experience, tends to be towards making >> the large(ish) ISPs happy and the majority of enterprises >> are a secondary consideration. This makes sense when you >> consider that the average large(ish) ISP spends several >> million dollars per year with their router vendor(s) of >> choice, while the rest of the world is significantly less >> per enterprise (in most cases) spread over a much wider >> collection of sales representatives. In most sales-oriented >> organizations (which as near as I can tell, all the hardware >> vendors are today), the sales rep with the largest dollar >> value tends to have the largest say in the feature priorities. >> > > When I raise this issue with vendors and ask if other ISPs are > concered > abot this they say that the question is very interesting, they have > not > beeing looking at the loing term impact of IPv6 on the routing > table size > and I am the first to provid some numbers of how big and by when. > > ___Jason > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From tme at multicasttech.com Fri Apr 28 09:45:20 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 28 Apr 2006 09:45:20 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: References: Message-ID: (I realized that I incorrectly included the intentional de-aggregates in the 7 year table at the bottom here, which messed up the table thoroughly, so I am just resending this with those numbers plus a typo corrected. It doesn't change much, and actually improves the agreement with my estimates. Please just disregard the previous version, and accept my apologies for the excess bandwidth.) Dear Jason; Thank you for this information. I have been coming at this from the other direction (I, also, have been flying a lot this week!), let's see if the lines cross somewhere. On Apr 27, 2006, at 5:45 PM, Jason Schiller (schiller at uu.net) wrote: > On Thu, 27 Apr 2006, Owen DeLong wrote: > >> Date: Thu, 27 Apr 2006 01:03:08 -0700 >> From: Owen DeLong >> To: "Jason Schiller (schiller at uu.net)" , >> Arin Archive >> Cc: ppml at arin.net >> Subject: Re: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 >> >> >> On the other side of those who remember, we have group D. This >> group is not ignorant of the limitations of the routing system. >> We are not (yes, I consider myself a member of group D) unaware >> of the issues with routing table growth in the current architecture. >> However, we also remember that one of the primary goals for the >> development of v6 was to FIX THIS. So far, it hasn't been fixed. >> Between v4 and v6, really, nothing changed in terms of routing. >> >> However, for both v4 and v6, I am convinced that these issues >> are far less urgent today, although I agree the problem has not >> been completely solved. Fortunately, I think the problem _CAN_ >> be solved and that we have approximately 10 years to solve it. > > IPv6 had as its goal to provide enough address space. It did that, > but > that also has implications on the global routing table. This is > why it is > suggested that there be an architectural approach to solving PI, > multi-homing, and mobility problems that do not rely on de- > aggregation. > > A solution with a complete locator/ID split would probably work, > but the > shim6 working group doesn't seem to want to indulge the traffic > engineering needs or requirements of the service providers, content > providers or large enterprise customers who beleive IPv6 traffic > engineering should be at least as functional as IPv4 traffic > engineering. > > Accepting this PI policy sends the signal that de-aggregation is an > acceptable solution. Maybe people might think it is a good idea to > allow > PI /64s (or /48s) for cell phones into the global routing table to > allow them to be mobile. > >> >> Here's how I figure it: >> >> 1. The current routing table is comprised of just over 20,000 >> active ASNs. The current v4 Prefix:ASN ratio is close to 8:1 >> on average, with the peaks advertisers being several hundred >> and the lows being 1. In the v6 world, this number should be >> much much closer to 1:1, probably somewhere around 2:1 will >> be realistic. That means that the current routing table >> translated to a v6 world will shrink to less than 50,000 routes. >> That should give us lots of headroom for v6 growth as v4 >> becomes less and less prevalant and eventually is not >> globally routed. > > It is very clear to me that people advertise more specific slices > of their > aggrgegate to do traffic engineering. Why do you think the number of > extra more specific slices for traffic engineering will be reducted to > 2:1? > > The way I see it by translating the IPv4 table into IPv6 you have the > following. Start with the CIDR report: > Recent Table History > Date Prefixes CIDR Agg > 03-03-06 179530 118693 > AS Summary > 21636 Number of ASes in routing system > > Divide the IPv4 table into three types of routes > 1. Aggregates > 2. De-aggergates that result from adding a second non-contigous block > (these will go away with IPv6 as the initial assignment will be > large) > 3. De-aggergates that result from dividing an aggrgegate for traffic > engineering It is apparent to me that some multiple address blocks represent hidden autonomous systems. I have had several enterprise network architects tell me things along the line of "we have N address blocks, one for each location where we have a presence, and they have separate upstream providers, but we just don't feel like getting / paying for an ASN for each one of these". These clearly will not be aggregated; it is not clear to me how many CIDR aggregates fall into this class, but I suspect some do. > > Take the number of Internet routes and subtract the number of > potentitial > CIDR aggrgegates 179530 - 118693 = 60837 This is roughly the > number of > de-aggergates for traffic engineering. > Don't almost all of these fall in category 3 ? In addition, won't NONE of the category 2's (the address blocks are not contiguous, after all) be potential CIDR aggregates ? So it's not clear to me how good an estimate this is. In the spirit of back of the envelope estimates for years into the future, I will buy it, but we might be able to a better job defragmenting the address space. > So the IPv4 Internet routing table is 179,530 > > The IPv6 Internet routing table is the number of IPv6 de-aggergates > for > traffic engineering + one aggregate per ASN. (This assumes that > the same > TE practices in IPv4 will be carried over to IPv6) 21636 + 60837 = > 82473 > > Thats 179,530 IPv4 Internet routes > + 82,473 IPv6 Internet routes > -------------------------------- > 262,003 IPv4/IPv6 Internet routes > > Add to that internal more specifics which for a large ISP is between > 50,000 and 150,000. And add to that IPv6 internal more specifics say > between 40,000 and 120,000. That somewhere between 352,003 and > 532,003 > routes assuing everyone does dual stack tomarrow. > > I know that there will be some ramp up period, but we need to > understand > what the routing table will look like once there is wide spread > adoption... You can argue when wide spread adoptioin will happen, and > project out IPv4 Internet growth, IPv4 de-aggergates for traffic > engineering, and number of ASNs and get a reasonable number of what > the > IPv6 routing table will be given normal growth and solving multi- > homing > with more specifics in the same way as IPv4. > > So I don't think it is unreasonable to think on the agressive side > that > there might be fairly good adoption of IPv6 by 2013. My > projections show > 1.3M routes by 2013... That means if I want to upgrade a router > now, and > it takes 2 years to certify and fully replace my existing network > and I > want to depreciate the cost of the router over 5 years, then I need > to buy > routers that support 2.3M routes. Isn't this a typo, shouldn't it be "1.3M routes" ? Otherwise, I don't see where it comes from. I actually think that these numbers are not too far out of line; the question is, is the time line out of line ? The US Small Business Administration http://www.sba.gov/advo/research/us_03ss.pdf estimates that there were 5,696,600 employer firms in 2003, 99.7 percent of which are small firms (i.e., there are 17090 non small firms, with 500 or more employees). Of the employer firms, there are 2,262,695 with 5 or more employees, and 1,237,198 with 10 or more employees. I think that a reasonable upper bound for the potential number of ASNs in the US right now is the latter number. (Since the number of firms is not increasing exponentially as fast as routes are, and since I am resolutely in back of the envelope mode, I will assume that these numbers will be constant over the next decade.) Assume that the existing 182,282 routes that I see this afternoon are all due to large businesses, and that these can be aggregated to 82,473 routes, as your numbers suggest. This would suggest that the US might add (1,237,198 - 82,473 =) 1,154,725 routes eventually. Since the US is roughly 1/5 of the global economy, that suggests that the total number of additional routes might be as large as 6 million. The real question is, by when ? I get a doubling time in the number of route of ~ 6.5 years from my data. I do not see a formal doubling time estimate in your presentation, but you must have estimated it or the equivalent, to get your power law projections, so I would be curious to hear what it is. I don't see it as being too much different from your graphs. 182,000 to 6 million routes is 5.0 doublings, which means that I would predict that the system would saturate (without artificial constraints) in 33 years, and would reach 1 million routes in about 2.46 doublings, or ~ 16 years, or 2022. If you assume a doubling time of 5 years (which is not supported by the data, but let's assume things speed up to be conservative), we get saturation in 20 years, and 1 million routes in 12.3 years, or 2018. Note that if you can get a factor of 2 now by defragmenting the address space, that adds 1 doubling time (~ 6 years or more) to all of these estimates. Note also that you are assuming that most routes are doubled in v4 and v6, so that costs you a doubling time if there is no defragmentation. Let's assume that that is true, and that there is no defragmentation (to be conservative), I get and 1 million routes in 9.5 years, or late 2016. If (more reasonably, and more in line with your estimates), you assume a 50 % defragmentation of the IPv6 address space, and otherwise a sharing of space between v4 and v6 (i.e., assuming that every path is represented in both address spaces), then you get an address space predictor of (1.5 x 2^(# doublings)), or 1 million routes in 1.87 doubling times, or 12 years. (Hopefully IPv4 growth would actually start to slow at some point in this future, so I regard this as a pretty conservative estimate.) So, I would estimate that 1 million external routes (with no artificial constraints) should be achieved somewhere in the 2016 to 2022 time frame, and saturation somewhere around 2030 to 2040. (For saturation, you clearly also have to include an estimate of global economic growth in the next few decades, which would take us way off into the weeds.) Of course, I understand from your presentation that you get that number by including internal routes, so let's look at them too. > > The next question is translating number of routes into RIB size FIB > size, > CPU speed, etc... Geoff Hustom has done some studies in this area... > > Take a look at the slides from GROW at IETF 65: > > http://www3.ietf.org/proceedings/06mar/slides/grow-1.pdf > http://www3.ietf.org/proceedings/06mar/slides/grow-0.pdf > http://www3.ietf.org/proceedings/06mar/slides/grow-3.pdf > > My projections are covered in the middle link. > OK, 2013 is 7 years from now, so let's look at your 7 year predictions. For ease of discussion, I will reproduce these here, rounded off : IPv4 routes : 339,000 Projected IPv6 : 237,000 Projected internal IPv4 (low) : 49,000 Projected internal IPv4 (high): 360,000 Projected internal IPv6 (low) : 132,000 Projected internal IPv6 (high): 404,000 Total External : 576,000 ( 41 % are IPv6) Total Internal (low) : 181,000 Total Internal (high) : 764,000 Totals (low) : 825,000 ( 29 % are IPv6 external) Totals (high) : 1,340,000 ( 18 % are IPv6 external) (Seven years is just a little over one doubling time from the present; I would predict a total of 576,000 v4 + v6 external routes then, an amazing agreement for anything back of the envelope.) So, for the 1.3 million route router you need to buy now, if SHIM6 was working today, and there were NO IPv6 routes required at all (ok, 1), then you would need to buy a 699,000 route router just to support IPv4. If you want to support IPv4 plus IPv6 (internal only), that's 1.1 million routes. So, I do not see that external IPv6 routing policy is driving your router purchases in the 7 year time horizon. Please correct me if I am wrong. Also, aren't internal routes something you have some control over ? I.e., isn't this something that you are paid to do, so if they are too expensive to support you can raise your prices, encourage aggregation, sub-divide your network, etc. ? Note, by the way, that even the most aggressive SHIM6 proponents don't predict its world domination in less than 7 years, so it's not likely to help much here. So, as a small multi-homer, I do not see a need to support 1.3 million routes in 7 years, but I do see a need to support 600,000, which may not be that different in practice. What I frankly do not see in all of these numbers is a reason not to support 2005-1. Regards Marshall >> >> 2. It is unlikely that the internet will see anywhere near the >> explosive growth of the 90s in the next 5-10 years. Even if it >> did, we would still stay well short of 160,000 v6 routes which >> is well under most estimates I've heard for current hardware >> capability. As such, there shouldn't be much of a problem >> for at least 10 years. >> >> 3. The large(ish) ISPs comprise the majority of the operational >> focus in the IETF, and, indeed have been a strong enough force >> there that they were able to get RFCs cranked out which >> attempted to preserve a completely provider-dependent >> addressing model for the v6 internet. As such, faced with >> building a scalable routing system or waiting for the network >> to implode, I would hope that they will start working towards >> a more scalable solution, such as ID/LOC splits. > > I don't think there is enough operator support in IETF. Clearly the > operators don't carry that much wieght. We can't get shim6 to > consider > current operational traffic engineering preferences as a "requirement" > > >> >> 4. I think that if IETF and large(ish) ISPs and router vendors >> work towards a solution, 10 years is more than enough time for >> development, testing, and, early deployment. > > I need a solution 7 years ahead of the day routers start crashing. > >> >> 5. Vendor focus, in my experience, tends to be towards making >> the large(ish) ISPs happy and the majority of enterprises >> are a secondary consideration. This makes sense when you >> consider that the average large(ish) ISP spends several >> million dollars per year with their router vendor(s) of >> choice, while the rest of the world is significantly less >> per enterprise (in most cases) spread over a much wider >> collection of sales representatives. In most sales-oriented >> organizations (which as near as I can tell, all the hardware >> vendors are today), the sales rep with the largest dollar >> value tends to have the largest say in the feature priorities. >> > > When I raise this issue with vendors and ask if other ISPs are > concered > abot this they say that the question is very interesting, they have > not > beeing looking at the loing term impact of IPv6 on the routing > table size > and I am the first to provid some numbers of how big and by when. > > ___Jason > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Fri Apr 28 10:16:28 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 28 Apr 2006 09:16:28 -0500 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 References: Message-ID: <083001c66ace$57bf7450$56b3db18@ssprunk> Thus spake "Marshall Eubanks" > On Apr 27, 2006, at 5:45 PM, Jason Schiller (schiller at uu.net) wrote: >> So I don't think it is unreasonable to think on the agressive side >> that there might be fairly good adoption of IPv6 by 2013. My >> projections show 1.3M routes by 2013... That means if I want to >> upgrade a router now, and it takes 2 years to certify and fully >> replace my existing network and I want to depreciate the cost >> of the router over 5 years, then I need to buy routers that >> support 2.3M routes. > > Isn't this a typo, shouldn't it be "1.3M routes" ? Otherwise, I don't > see where it comes from. > > I actually think that these numbers are not too far out of line; the > question is, is the time line out of line ? > > The US Small Business Administration > > http://www.sba.gov/advo/research/us_03ss.pdf > > estimates that there were 5,696,600 employer firms in 2003, 99.7 > percent of which are small firms > (i.e., there are 17090 non small firms, with 500 or more employees). > Of the employer firms, there are 2,262,695 with 5 or more > employees, and 1,237,198 with 10 or more employees. I think that a > reasonable upper bound for the > potential number of ASNs in the US right now is the latter number. > (Since the number of firms is not increasing exponentially as fast > as routes are, and since I am resolutely in back of the envelope > mode, I will assume that these numbers will be constant over the next > decade.) 2005-1 effectively requires 512 hosts (and 2 pipes) to get a PIv6 block, so the expected number of assignments under that policy should be 17k. It's also reasonable to expect most of those assignments will be minimum-sized, so ISPs will be able to keep them down to 1 slot/org by filtering anything longer than /48. I don't think anyone here is proposing, even as a joke, giving PI space to orgs with 5-10 employees/hosts. > So, as a small multi-homer, I do not see a need to support 1.3 > million routes in 7 years, but I do see a need to support 600,000, > which may not be that different in practice. What I frankly do not > see in all of these numbers is a reason not to support 2005-1. Ditto, though I come at it from a different angle: no matter how much one may complain about PIv6, PIv4 is an order of magnitude worse, so as long as v4 is still natively routed and policies are similar, the IPv6 routing table size is not going to drive router upgrades -- v4 and VPNs will. If anything, the cost of constant upgrades to support the bloated v4 table should be viewed as motivation to get customers moving to IPv6. As much as one may dislike PIv6, one route/ASN is a lot cheaper to build routers for than today's nearly 10 routes/ASN. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From tme at multicasttech.com Fri Apr 28 10:39:47 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 28 Apr 2006 10:39:47 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: <083001c66ace$57bf7450$56b3db18@ssprunk> References: <083001c66ace$57bf7450$56b3db18@ssprunk> Message-ID: <997B8977-B018-4733-8CE0-34F36D067B81@multicasttech.com> Hello; On Apr 28, 2006, at 10:16 AM, Stephen Sprunk wrote: > Thus spake "Marshall Eubanks" >> On Apr 27, 2006, at 5:45 PM, Jason Schiller (schiller at uu.net) wrote: >>> So I don't think it is unreasonable to think on the agressive side >>> that there might be fairly good adoption of IPv6 by 2013. My >>> projections show 1.3M routes by 2013... That means if I want to >>> upgrade a router now, and it takes 2 years to certify and fully >>> replace my existing network and I want to depreciate the cost >>> of the router over 5 years, then I need to buy routers that >>> support 2.3M routes. >> >> Isn't this a typo, shouldn't it be "1.3M routes" ? Otherwise, I don't >> see where it comes from. >> >> I actually think that these numbers are not too far out of line; the >> question is, is the time line out of line ? >> >> The US Small Business Administration >> >> http://www.sba.gov/advo/research/us_03ss.pdf >> >> estimates that there were 5,696,600 employer firms in 2003, 99.7 >> percent of which are small firms >> (i.e., there are 17090 non small firms, with 500 or more employees). >> Of the employer firms, there are 2,262,695 with 5 or more >> employees, and 1,237,198 with 10 or more employees. I think that a >> reasonable upper bound for the >> potential number of ASNs in the US right now is the latter number. >> (Since the number of firms is not increasing exponentially as fast >> as routes are, and since I am resolutely in back of the envelope >> mode, I will assume that these numbers will be constant over the next >> decade.) > > 2005-1 effectively requires 512 hosts (and 2 pipes) to get a PIv6 > block, so the expected number of assignments under that policy > should be 17k. It's also reasonable to expect most of those > assignments will be minimum-sized, so ISPs will be able to keep > them down to 1 slot/org by filtering anything longer than /48. > > I don't think anyone here is proposing, even as a joke, giving PI > space to orgs with 5-10 employees/hosts. Cool, but that's not quite the point. I don't see PI space being driven down further than that, so I regard that (actually, 10 or more employees) as an _upper bound_. Anything that makes it lower makes my numbers safer. This email was engendered from a lunchtime discussion with Vince Fuller and Dave Meyer and others at RIPE. My feeling was that the arguments about scaling etc. are futile unless you know "scaling until what ?", and the only way to do that is to try and estimate firm upper bounds with assumptions that can be argued. (For example, if you say that I am off by a factor in the total number of entities with PI space, or that my doubling times are off, or whatever, it's easy to recalculate these numbers.) Regards Marshall > >> So, as a small multi-homer, I do not see a need to support 1.3 >> million routes in 7 years, but I do see a need to support 600,000, >> which may not be that different in practice. What I frankly do not >> see in all of these numbers is a reason not to support 2005-1. > > Ditto, though I come at it from a different angle: no matter how > much one may complain about PIv6, PIv4 is an order of magnitude > worse, so as long as v4 is still natively routed and policies are > similar, the IPv6 routing table size is not going to drive router > upgrades -- v4 and VPNs will. > > If anything, the cost of constant upgrades to support the bloated > v4 table should be viewed as motivation to get customers moving to > IPv6. As much as one may dislike PIv6, one route/ASN is a lot > cheaper to build routers for than today's nearly 10 routes/ASN. > > S > > Stephen Sprunk "Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin From jason.schiller at mci.com Fri Apr 28 10:57:22 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Fri, 28 Apr 2006 10:57:22 -0400 (EDT) Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: Message-ID: Yeah! someone else is actaully thinking about the long term implacations of PI. :-) These are the types of discussions that need to be fully flushed out before we all commit to embarking on this path. On Fri, 28 Apr 2006, Marshall Eubanks wrote: > (I realized that I incorrectly included the intentional de-aggregates > in the 7 year table at the bottom here, which messed up the table > thoroughly, so I am just resending this with those numbers plus a typo > corrected. It doesn't change much, and actually improves the > agreement with my estimates. Please > just disregard the previous version, and accept my apologies for the > excess bandwidth.) > > Dear Jason; > > Thank you for this information. I have been coming at this from the > other direction (I, also, > have been flying a lot this week!), let's see if the lines cross > somewhere. > > On Apr 27, 2006, at 5:45 PM, Jason Schiller (schiller at uu.net) wrote: > > > On Thu, 27 Apr 2006, Owen DeLong wrote: > > > >> Date: Thu, 27 Apr 2006 01:03:08 -0700 > >> From: Owen DeLong > >> To: "Jason Schiller (schiller at uu.net)" , > >> Arin Archive > >> Cc: ppml at arin.net > >> Subject: Re: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 > >> > >> > >> On the other side of those who remember, we have group D. This > >> group is not ignorant of the limitations of the routing system. > >> We are not (yes, I consider myself a member of group D) unaware > >> of the issues with routing table growth in the current architecture. > >> However, we also remember that one of the primary goals for the > >> development of v6 was to FIX THIS. So far, it hasn't been fixed. > >> Between v4 and v6, really, nothing changed in terms of routing. > >> > >> However, for both v4 and v6, I am convinced that these issues > >> are far less urgent today, although I agree the problem has not > >> been completely solved. Fortunately, I think the problem _CAN_ > >> be solved and that we have approximately 10 years to solve it. > > > > IPv6 had as its goal to provide enough address space. It did that, > > but > > that also has implications on the global routing table. This is > > why it is > > suggested that there be an architectural approach to solving PI, > > multi-homing, and mobility problems that do not rely on de- > > aggregation. > > > > A solution with a complete locator/ID split would probably work, > > but the > > shim6 working group doesn't seem to want to indulge the traffic > > engineering needs or requirements of the service providers, content > > providers or large enterprise customers who beleive IPv6 traffic > > engineering should be at least as functional as IPv4 traffic > > engineering. > > > > Accepting this PI policy sends the signal that de-aggregation is an > > acceptable solution. Maybe people might think it is a good idea to > > allow > > PI /64s (or /48s) for cell phones into the global routing table to > > allow them to be mobile. > > > >> > >> Here's how I figure it: > >> > >> 1. The current routing table is comprised of just over 20,000 > >> active ASNs. The current v4 Prefix:ASN ratio is close to 8:1 > >> on average, with the peaks advertisers being several hundred > >> and the lows being 1. In the v6 world, this number should be > >> much much closer to 1:1, probably somewhere around 2:1 will > >> be realistic. That means that the current routing table > >> translated to a v6 world will shrink to less than 50,000 routes. > >> That should give us lots of headroom for v6 growth as v4 > >> becomes less and less prevalant and eventually is not > >> globally routed. > > > > It is very clear to me that people advertise more specific slices > > of their > > aggrgegate to do traffic engineering. Why do you think the number of > > extra more specific slices for traffic engineering will be reducted to > > 2:1? > > > > The way I see it by translating the IPv4 table into IPv6 you have the > > following. Start with the CIDR report: > > Recent Table History > > Date Prefixes CIDR Agg > > 03-03-06 179530 118693 > > AS Summary > > 21636 Number of ASes in routing system > > > > Divide the IPv4 table into three types of routes > > 1. Aggregates > > 2. De-aggergates that result from adding a second non-contigous block > > (these will go away with IPv6 as the initial assignment will be > > large) > > 3. De-aggergates that result from dividing an aggrgegate for traffic > > engineering > > It is apparent to me that some multiple address blocks represent > hidden autonomous > systems. I have had several enterprise network architects tell me > things along the line of > "we have N address blocks, one for each location where we have a > presence, and they have separate > upstream providers, but we just don't feel like getting / paying for > an ASN for each one of > these". These clearly will not be aggregated; it is not clear to me > how many CIDR aggregates fall into > this class, but I suspect some do. Yes, I agree, but I can't figure out how to measure this. My number assume that all non-contigous blocks from a single AS will be replaced with one block... this may be too agressive. Take the case where a single AS exists as 2 seperate stub networks connecting to two upstream ISPs. Each stub has a non-contigous /24. In IPv6 we give them a /48, but they will still announce two routes. My calculations assume only a single route. The same might be true for a single site with two non-contigous /24, if given a /23 they might still announce 2* /24s for traffic engineering purposes. > > > > > > Take the number of Internet routes and subtract the number of > > potentitial > > CIDR aggrgegates 179530 - 118693 = 60837 This is roughly the > > number of > > de-aggergates for traffic engineering. > > > > Don't almost all of these fall in category 3 ? In addition, won't > NONE of the category 2's > (the address blocks are not contiguous, after all) be potential CIDR > aggregates ? So it's not > clear to me how good an estimate this is. In the spirit of back of > the envelope estimates for > years into the future, I will buy it, but we might be able to a > better job defragmenting the > address space. I'm not sure I follow here... the CIDR report shows 179503 routes, that could be aggregated down to 118693 routes. that meanse 118693 routes can't easily be aggregate today, but 60837 could be aggregated. To say it another way 60837 are intentionally not aggregated. > > > So the IPv4 Internet routing table is 179,530 > > > > > The IPv6 Internet routing table is the number of IPv6 de-aggergates > > for > > traffic engineering + one aggregate per ASN. (This assumes that > > the same > > TE practices in IPv4 will be carried over to IPv6) 21636 + 60837 = > > 82473 > > > > Thats 179,530 IPv4 Internet routes > > + 82,473 IPv6 Internet routes > > -------------------------------- > > 262,003 IPv4/IPv6 Internet routes > > > > Add to that internal more specifics which for a large ISP is between > > 50,000 and 150,000. And add to that IPv6 internal more specifics say > > between 40,000 and 120,000. That somewhere between 352,003 and > > 532,003 > > routes assuing everyone does dual stack tomarrow. > > > > I know that there will be some ramp up period, but we need to > > understand > > what the routing table will look like once there is wide spread > > adoption... You can argue when wide spread adoptioin will happen, and > > project out IPv4 Internet growth, IPv4 de-aggergates for traffic > > engineering, and number of ASNs and get a reasonable number of what > > the > > IPv6 routing table will be given normal growth and solving multi- > > homing > > with more specifics in the same way as IPv4. > > > > So I don't think it is unreasonable to think on the agressive side > > that > > there might be fairly good adoption of IPv6 by 2013. My > > projections show > > 1.3M routes by 2013... That means if I want to upgrade a router > > now, and > > it takes 2 years to certify and fully replace my existing network > > and I > > want to depreciate the cost of the router over 5 years, then I need > > to buy > > routers that support 2.3M routes. > > Isn't this a typo, shouldn't it be "1.3M routes" ? Otherwise, I don't > see where it comes from. sorry yes, 1.3M in 7 years > > I actually think that these numbers are not too far out of line; the > question is, is the > time line out of line ? > The question I am trying to answer is in the long term when there is wide spread adoption of IPv6 how bad is de-aggregation as a solution for PI and multi-homing. What would it mean if wide spread adoption happend by tomarrow? By 7 years from now? and so on. The next question is do you want to commit to the course of action and risk the health of your network on faith that routers big enough will be ready soon enough? Your numbers are interesting, can you provide 5, 7, 10, and 14 year numbers? These are the numbers that are interesting to me when discussing router purchasing. > The US Small Business Administration > > http://www.sba.gov/advo/research/us_03ss.pdf > > estimates that there were 5,696,600 employer firms in 2003, 99.7 > percent of which are small firms > (i.e., there are 17090 non small firms, with 500 or more employees). > Of the employer firms, there are 2,262,695 with 5 or more > employees, and 1,237,198 with 10 or more employees. I think that a > reasonable upper bound for the > potential number of ASNs in the US right now is the latter number. > (Since the number of firms is not increasing exponentially as fast > as routes are, and since I am resolutely in back of the envelope > mode, I will assume that these numbers will be constant over the next > decade.) > > Assume that the existing 182,282 routes that I see this afternoon are > all due to > large businesses, and that these can be aggregated to 82,473 routes, > as your numbers suggest. > > This would suggest that the US might add (1,237,198 - 82,473 =) > 1,154,725 routes eventually. > Since the US is roughly 1/5 of the global economy, that suggests that > the total number of additional > routes might be as large as 6 million. > So all small business will either not multi-home or will use the limited functionality of shim6 when it is available? What about Europe, Asia, Latin America, Canada?? Suppose I built a scenerio like this. There are 1 billion people in China. 10% of them have a cell phone. Thats 100 million cell phones. One quarter of these phones will run IPv6, and want mobility. As IETF hasn't solved the mobility problem yet, lets use PI addresses to make mobility work. As long as each phone get a PI /64 and advertises it to their particular Cell provider or particular cell tower, then roaming just works. Thats 25 million new routes in the table. > The real question is, by when ? I get a doubling time in the number > of route of ~ 6.5 years from my data. I > do not see a formal doubling time estimate in your presentation, > but you must have estimated it or the equivalent, to get > your power law projections, so I would be curious to hear what it is. > I don't see it as being too much different from your graphs. > > 182,000 to 6 million routes is 5.0 doublings, which means that I > would predict that the system would saturate > (without artificial constraints) in 33 years, and would reach 1 > million routes in about 2.46 doublings, or > ~ 16 years, or 2022. If you assume a doubling time of 5 years (which > is not supported by the data, but let's > assume things speed up to be conservative), we get saturation in 20 > years, and 1 million routes in 12.3 years, > or 2018. > > Note that if you can get a factor of 2 now by defragmenting the > address space, that adds 1 doubling time (~ 6 years or more) to all > of these estimates. Note also that you are assuming that most routes > are doubled in v4 and v6, so that costs you a doubling time if there > is no defragmentation. Let's assume that that is true, and that there > is no defragmentation (to be conservative), I get and 1 million > routes in 9.5 years, or late 2016. If (more reasonably, and more in > line with your estimates), you assume a 50 % defragmentation > of the IPv6 address space, and otherwise a sharing of space between > v4 and v6 (i.e., assuming that every path > is represented in both address spaces), then you get an address space > predictor of (1.5 x 2^(# doublings)), or > 1 million routes in 1.87 doubling times, or 12 years. (Hopefully > IPv4 growth would actually start to slow at > some point in this future, so I regard this as a pretty conservative > estimate.) > You raise an interesting question that i suspect ARIN will not address, should multi-homers only get one slot in the global routing table (i.e. 1* /48) or multiple slots to allow for traffic engineering. My predictions certainly assume multiple slots, and would be less agressive If there was only one slot. This would make the IPv6 table as large as the number of ASes in the system which as you point out is linear not quadratic. :-), but this also does not solve the traffic engineering problem. > So, I would estimate that 1 million external routes (with no > artificial constraints) should be achieved somewhere in the 2016 to > 2022 time frame, and saturation somewhere around 2030 to 2040. (For > saturation, you clearly also > have to include an estimate of global economic growth in the next few > decades, which would take us way > off into the weeds.) > > Of course, I understand from your presentation that you get that > number by including internal routes, so > let's look at them too. > > > > > The next question is translating number of routes into RIB size FIB > > size, > > CPU speed, etc... Geoff Hustom has done some studies in this area... > > > > Take a look at the slides from GROW at IETF 65: > > > > http://www3.ietf.org/proceedings/06mar/slides/grow-1.pdf > > http://www3.ietf.org/proceedings/06mar/slides/grow-0.pdf > > http://www3.ietf.org/proceedings/06mar/slides/grow-3.pdf > > > > My projections are covered in the middle link. > > > > OK, 2013 is 7 years from now, so let's look at your 7 year predictions. > > For ease of discussion, I will reproduce these here, rounded off : > > IPv4 routes : 339,000 > Projected IPv6 : 237,000 > > Projected internal IPv4 (low) : 49,000 > Projected internal IPv4 (high): 360,000 > > Projected internal IPv6 (low) : 132,000 > Projected internal IPv6 (high): 404,000 > > Total External : 576,000 ( 41 % are IPv6) > Total Internal (low) : 181,000 > Total Internal (high) : 764,000 > > Totals (low) : 825,000 ( 29 % are IPv6 external) > Totals (high) : 1,340,000 ( 18 % are IPv6 external) > > > (Seven years is just a little over one doubling time from the present; I > would predict a total of 576,000 v4 + v6 external routes then, an > amazing agreement > for anything back of the envelope.) > > So, for the 1.3 million route router you need to buy now, if SHIM6 > was working today, and > there were NO IPv6 routes required at all (ok, 1), then you would > need to buy a 699,000 route > router just to support IPv4. If you want to support IPv4 plus IPv6 > (internal only), that's > 1.1 million routes. > > So, I do not see that external IPv6 routing policy is driving your > router purchases in the 7 year > time horizon. Please correct me if I am wrong. Assume I have to purchase ne routers today. Are the routers I can buy today big enought to not be upgraded in 7 years. And again in seven years time, are the routers I can buy big enough to not need to be upgraded in 7 years. Yes it is a factor of a bunch of things, and worst offender is IPv4 the IPv4 Internet table. But the IPv4 de-aggrgegates for traffic engineering are growing at a faster rate than the total IPv4 table. And sure you can prevent IPv6 for inheriting this growth by making it commonly accepted policy that any ASN should only advertise a single aggrgegate to the Internet table. Shim6 might ease this a bit when its available for people who haven't already adopted BGP based traffic engineering. 8+8 GSE may ease this a bit more for people who haven't already adopted BGP based traffic engineering and need complex traffic engineer capabilities. ___Jason From marla_azinger at eli.net Fri Apr 28 11:31:50 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 28 Apr 2006 08:31:50 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D14@wava00s2ke2k01.corp.pvt> >Michel Py wrote: Because it's the official line of the party. The very fact that 2005-1 >is going to last call is the official failure notice of shim6. I look at this from a different view. I see 2005-1 as one solution for a couple different "issues". However, I also believe policy can change. So why shouldnt this policy just be motivation to make shim 6 work? Policy is not set in stone and can always be changed if given reason and support to do so. Marla -----Original Message----- From: Michel Py [mailto:michel at arneill-py.sacramento.ca.us] Sent: Friday, April 28, 2006 12:27 AM To: Azinger, Marla Cc: ppml at arin.net Subject: RE: [ppml] "Recommended Practices" procedure > Marla Azinger wrote: > If work on 8+8 truly stopped completely and nobody is looking > at it at all, then I'm curious why it still comes up in > conversation as one of the possible fixes (given improvement). A mix of "maybe I should not had given up on it", "I told you so" and "if only you had listened to what I said or read what I wrote 5 years ago". > However, that said, I do hear Shim 6 mentioned much more and > how this one might be the best chance at creating a solution. Because it's the official line of the party. The very fact that 2005-1 is going to last call is the official failure notice of shim6. > I don't believe that Shim 6 has been disbanded yet. It won't anytime soon. Utopias live forever. > I believe working on improving shim 6 or resurrecting others > and improving them would be done because "some of us care" > (I'm sure I can hear some laughter out there, but I care). That's what I believed when I started ipv6mh in early 2002. multi6 was virtually dead, and many people have told me privately that the only thing ipv6mh ever achieved was to maintain the illusion of a workable IPv6 multihoming solution. In other words, if I just had let multi6 die in 2002 we would not have wasted 4 more years for someone to put on the table a PI policy. > however I believe supporting both sides of the coin. One > being we want to multihome and two being we need to keep > the routing tables healthy. A lot of very bright people, many of them with the right political connections have tried for more than 10 years. All have failed; as the self-appointed curator of the failed IPv6 multihoming solutions museum, I can tell you that there's a lot on display already and I still could dig a few skeletons out of the closet. > I'm an optimist The time when IPv6 could be deployed with optimism has come and gone. > Owen DeLong wrote: > I agree that the IETF lacks operational focus. However, it is > the large ISPs and router vendors that shouted loudest to avoid > PI space, and, these are the groups that continue to shout the > loudest. That is simply a fact. Ack. > I'm not saying that there's any sort of conspiracy between vendors > and largeISPs. I'm saying that vendors are over-represented in the > IETF, large operators are underrepresented, and, enterprise and > smaller consumers are virtually un-represented. Another over-represented group is the academia. > I don't think that the IETF acted in bad faith, and, I'm not > trying to make any such accusation. I do think that the IETF > failed to deliver a scalable routing solution and continues > to focus on dead-end paths that do not offer any possibility > of real solution. Ack this too. > Further, I do think that the large ISPs have a profit > motive to preserve a PA only addressing model Of course they have. Customer lock-in. The fact of the matter is that PA-only is good for large, already established ISPs (which happens to be the ones with lobbying dollars to stuff IETF and ARIN meetings) while smaller ISPs trying to get in would likely favor policies that let them compete on service. I found a rather interesting correlation between ISP size and their support of or opposition to 2005-1, actually :-D Michel. From marla_azinger at eli.net Fri Apr 28 11:45:57 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 28 Apr 2006 08:45:57 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A56E@wava00s2ke2k01.corp.pvt> Randy wrote: >this is an ops community, best current practice is defind by actual >practice, not documents that often have never even been tested in >practice I agree with this comment to some extent. But I believe we can also acheive having document that supports actual practice and gives guidance when we are dealing with something in its infancy (V6). Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Randy Bush Sent: Friday, April 28, 2006 12:07 AM To: Thomas Narten Cc: ppml at arin.net Subject: Re: [ppml] "Recommended Practices" procedure > They can, but what _official_ blessing would they have? (And some sort > of official blessing seems part of the point, so that it can > justifiably be called a 'best current practice'.) this is an ops community, best current practice is defind by actual practice, not documents that often have never even been tested in practice randy _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From jdhoule at att.com Fri Apr 28 13:19:57 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), BSMO) Date: Fri, 28 Apr 2006 12:19:57 -0500 Subject: [ppml] Setting policy v setting expectation was: "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D14@wava00s2ke2k01.corp.pvt> Message-ID: Marla et al: Policies can change... but that does not un-do what had been done under earlier policies. It may be near impossible to undo what gets done. Once ARIN policy allocates "site-sized" blocks for IPv6, the expectation to route /48-sized blocks will have been set. ARIN doesn't set routing policy, but ARIN policy does set expectation. I do not support this policy with the allocation size of /48. Joe Houle -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Azinger, Marla Sent: Friday, April 28, 2006 11:32 AM To: Michel Py Cc: ppml at arin.net Subject: Re: [ppml] "Recommended Practices" procedure >Michel Py wrote: Because it's the official line of the party. The very fact that 2005-1 >is going to last call is the official failure notice of shim6. I look at this from a different view. I see 2005-1 as one solution for a couple different "issues". However, I also believe policy can change. So why shouldnt this policy just be motivation to make shim 6 work? Policy is not set in stone and can always be changed if given reason and support to do so. Marla From tme at multicasttech.com Fri Apr 28 14:14:59 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 28 Apr 2006 14:14:59 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: References: Message-ID: Hello; On Apr 28, 2006, at 10:57 AM, Jason Schiller (schiller at uu.net) wrote: > Yeah! someone else is actaully thinking about the long term > implacations > of PI. :-) These are the types of discussions that need to be fully > flushed out before we all commit to embarking on this path. > > On Fri, 28 Apr 2006, Marshall Eubanks wrote: > >> (I realized that I incorrectly included the intentional de-aggregates >> in the 7 year table at the bottom here, which messed up the table >> thoroughly, so I am just resending this with those numbers plus a >> typo >> corrected. It doesn't change much, and actually improves the >> agreement with my estimates. Please >> just disregard the previous version, and accept my apologies for the >> excess bandwidth.) >> >> Dear Jason; >> >> Thank you for this information. I have been coming at this from the >> other direction (I, also, >> have been flying a lot this week!), let's see if the lines cross >> somewhere. >> >> On Apr 27, 2006, at 5:45 PM, Jason Schiller (schiller at uu.net) wrote: >> >>> On Thu, 27 Apr 2006, Owen DeLong wrote: >>> >>>> Date: Thu, 27 Apr 2006 01:03:08 -0700 >>>> From: Owen DeLong >>>> To: "Jason Schiller (schiller at uu.net)" , >>>> Arin Archive >>>> Cc: ppml at arin.net >>>> Subject: Re: [ppml] Policy Proposal 2005-1: Provider-independent >>>> IPv6 >>>> >>>> >>>> On the other side of those who remember, we have group D. This >>>> group is not ignorant of the limitations of the routing system. >>>> We are not (yes, I consider myself a member of group D) unaware >>>> of the issues with routing table growth in the current >>>> architecture. >>>> However, we also remember that one of the primary goals for the >>>> development of v6 was to FIX THIS. So far, it hasn't been fixed. >>>> Between v4 and v6, really, nothing changed in terms of routing. >>>> >>>> However, for both v4 and v6, I am convinced that these issues >>>> are far less urgent today, although I agree the problem has not >>>> been completely solved. Fortunately, I think the problem _CAN_ >>>> be solved and that we have approximately 10 years to solve it. >>> >>> IPv6 had as its goal to provide enough address space. It did that, >>> but >>> that also has implications on the global routing table. This is >>> why it is >>> suggested that there be an architectural approach to solving PI, >>> multi-homing, and mobility problems that do not rely on de- >>> aggregation. >>> >>> A solution with a complete locator/ID split would probably work, >>> but the >>> shim6 working group doesn't seem to want to indulge the traffic >>> engineering needs or requirements of the service providers, content >>> providers or large enterprise customers who beleive IPv6 traffic >>> engineering should be at least as functional as IPv4 traffic >>> engineering. >>> >>> Accepting this PI policy sends the signal that de-aggregation is an >>> acceptable solution. Maybe people might think it is a good idea to >>> allow >>> PI /64s (or /48s) for cell phones into the global routing table to >>> allow them to be mobile. >>> >>>> >>>> Here's how I figure it: >>>> >>>> 1. The current routing table is comprised of just over 20,000 >>>> active ASNs. The current v4 Prefix:ASN ratio is close to 8:1 >>>> on average, with the peaks advertisers being several hundred >>>> and the lows being 1. In the v6 world, this number should be >>>> much much closer to 1:1, probably somewhere around 2:1 will >>>> be realistic. That means that the current routing table >>>> translated to a v6 world will shrink to less than 50,000 routes. >>>> That should give us lots of headroom for v6 growth as v4 >>>> becomes less and less prevalant and eventually is not >>>> globally routed. >>> >>> It is very clear to me that people advertise more specific slices >>> of their >>> aggrgegate to do traffic engineering. Why do you think the >>> number of >>> extra more specific slices for traffic engineering will be >>> reducted to >>> 2:1? >>> >>> The way I see it by translating the IPv4 table into IPv6 you have >>> the >>> following. Start with the CIDR report: >>> Recent Table History >>> Date Prefixes CIDR Agg >>> 03-03-06 179530 118693 >>> AS Summary >>> 21636 Number of ASes in routing system >>> >>> Divide the IPv4 table into three types of routes >>> 1. Aggregates >>> 2. De-aggergates that result from adding a second non-contigous >>> block >>> (these will go away with IPv6 as the initial assignment will be >>> large) >>> 3. De-aggergates that result from dividing an aggrgegate for traffic >>> engineering >> >> It is apparent to me that some multiple address blocks represent >> hidden autonomous >> systems. I have had several enterprise network architects tell me >> things along the line of >> "we have N address blocks, one for each location where we have a >> presence, and they have separate >> upstream providers, but we just don't feel like getting / paying for >> an ASN for each one of >> these". These clearly will not be aggregated; it is not clear to me >> how many CIDR aggregates fall into >> this class, but I suspect some do. > > Yes, I agree, but I can't figure out how to measure this. > > My number assume that all non-contigous blocks from a single AS > will be ACK. I hadn't quite parse it that way, which makes things a bit clearer. > replaced with one block... this may be too agressive. Take the case > where a single AS exists as 2 seperate stub networks connecting to > two upstream ISPs. Each stub has a non-contigous /24. In IPv6 we > give > them a /48, but they will still announce two routes. My calculations > assume only a single route. The same might be true for a single > site with > two non-contigous /24, if given a /23 they might still announce 2* / > 24s > for traffic engineering purposes. > >> >> >>> >>> Take the number of Internet routes and subtract the number of >>> potentitial >>> CIDR aggrgegates 179530 - 118693 = 60837 This is roughly the >>> number of >>> de-aggergates for traffic engineering. >>> >> >> Don't almost all of these fall in category 3 ? In addition, won't >> NONE of the category 2's >> (the address blocks are not contiguous, after all) be potential CIDR >> aggregates ? So it's not >> clear to me how good an estimate this is. In the spirit of back of >> the envelope estimates for >> years into the future, I will buy it, but we might be able to a >> better job defragmenting the >> address space. > > I'm not sure I follow here... the CIDR report shows 179503 routes, > that > could be aggregated down to 118693 routes. that meanse 118693 routes > can't easily be aggregate today, but 60837 could be aggregated. To > say it > another way 60837 are intentionally not aggregated. See above. > > >> >>> So the IPv4 Internet routing table is 179,530 >> >>> >>> The IPv6 Internet routing table is the number of IPv6 de-aggergates >>> for >>> traffic engineering + one aggregate per ASN. (This assumes that >>> the same >>> TE practices in IPv4 will be carried over to IPv6) 21636 + 60837 = >>> 82473 >>> >>> Thats 179,530 IPv4 Internet routes >>> + 82,473 IPv6 Internet routes >>> -------------------------------- >>> 262,003 IPv4/IPv6 Internet routes >>> >>> Add to that internal more specifics which for a large ISP is between >>> 50,000 and 150,000. And add to that IPv6 internal more specifics >>> say >>> between 40,000 and 120,000. That somewhere between 352,003 and >>> 532,003 >>> routes assuing everyone does dual stack tomarrow. >>> >>> I know that there will be some ramp up period, but we need to >>> understand >>> what the routing table will look like once there is wide spread >>> adoption... You can argue when wide spread adoptioin will >>> happen, and >>> project out IPv4 Internet growth, IPv4 de-aggergates for traffic >>> engineering, and number of ASNs and get a reasonable number of what >>> the >>> IPv6 routing table will be given normal growth and solving multi- >>> homing >>> with more specifics in the same way as IPv4. >>> >>> So I don't think it is unreasonable to think on the agressive side >>> that >>> there might be fairly good adoption of IPv6 by 2013. My >>> projections show >>> 1.3M routes by 2013... That means if I want to upgrade a router >>> now, and >>> it takes 2 years to certify and fully replace my existing network >>> and I >>> want to depreciate the cost of the router over 5 years, then I need >>> to buy >>> routers that support 2.3M routes. >> >> Isn't this a typo, shouldn't it be "1.3M routes" ? Otherwise, I don't >> see where it comes from. > > sorry yes, 1.3M in 7 years > > >> >> I actually think that these numbers are not too far out of line; the >> question is, is the >> time line out of line ? >> > > The question I am trying to answer is in the long term when there > is wide > spread adoption of IPv6 how bad is de-aggregation as a solution for > PI and > multi-homing. What would it mean if wide spread adoption happend by > tomarrow? By 7 years from now? and so on. > Me too. > The next question is do you want to commit to the course of action and > risk the health of your network on faith that routers big enough > will be > ready soon enough? > Well, that is the other piece of this puzzle, and I would love to see some projections of router capacities. > Your numbers are interesting, can you provide 5, 7, 10, and 14 year > numbers? These are the numbers that are interesting to me when > discussing > router purchasing. Sure. Note that in all of this conservatism there is something an internal contradiction - we (me for sure, and I think you too) assume that, while IPv6 is adopted, it never really replaces v4. All boxes are eventually on both a v4 and a v6 path (in this conservative model), which must break down at some point (else, why adopt v6 ?). (This breakdown could take many forms - running out of room in IPv4, killer aps in IPv6, even an abandonment of v6 for something else, but for sure the factor of 1.5 won't last forever.) > >> The US Small Business Administration >> >> http://www.sba.gov/advo/research/us_03ss.pdf >> >> estimates that there were 5,696,600 employer firms in 2003, 99.7 >> percent of which are small firms >> (i.e., there are 17090 non small firms, with 500 or more employees). >> Of the employer firms, there are 2,262,695 with 5 or more >> employees, and 1,237,198 with 10 or more employees. I think that a >> reasonable upper bound for the >> potential number of ASNs in the US right now is the latter number. >> (Since the number of firms is not increasing exponentially as fast >> as routes are, and since I am resolutely in back of the envelope >> mode, I will assume that these numbers will be constant over the next >> decade.) >> >> Assume that the existing 182,282 routes that I see this afternoon are >> all due to >> large businesses, and that these can be aggregated to 82,473 routes, >> as your numbers suggest. >> >> This would suggest that the US might add (1,237,198 - 82,473 =) >> 1,154,725 routes eventually. >> Since the US is roughly 1/5 of the global economy, that suggests that >> the total number of additional >> routes might be as large as 6 million. >> > > So all small business will either not multi-home or will use the > limited > functionality of shim6 when it is available? As I said in another post, I don't see how you can get more conservative than that. I am trying for upper bounds, because I think that we can do that. My experience tells me, anyway, that if we are grossly off, it will be because of things we totally do not anticipate. > > What about Europe, Asia, Latin America, Canada?? > That's the global economy part. I am assuming something about the size of these other economies and how it scales to IP address requirements - effectively, that in the US, X employees means PI space, abroad, Y dollars of revenue mean PI space. However, this is resolutely BOTE (back of the envelope), and, I would strongly argue, that is literally all you can do when you start talking about 10+ years off. > Suppose I built a scenerio like this. There are 1 billion people in > China. 10% of them have a cell phone. Thats 100 million cell > phones. One quarter of these phones will run IPv6, and want > mobility. As > IETF hasn't solved the mobility problem yet, lets use PI addresses > to make > mobility work. As long as each phone get a PI /64 and advertises > it to > their particular Cell provider or particular cell tower, then > roaming just > works. Thats 25 million new routes in the table. > And maybe that will happen. Don't know, but I bet that if it does the 3G and 4G people will solve this at "Layer RF". The real question is when. The only firm things we know are the current usage and the current doubling time. My running through the numbers convinced me that the position that Vince Fuller forcefully argued at lunch is correct, and this growth will continue throughout most of the the rest of careers, if not our natural lives. So, unless there is a reason for the growth to become hyperexponential (with a doubling time for the doubling time), the end numbers are almost irrelevant; we literally may never live to see them. The growth, which we can predict, will likely continue throughout any reasonable time horizon for equipment purchases. If the equipment won't keep up, and the protocols can't be modified (link state BGP anyone?), then there is indeed a problem. >> The real question is, by when ? I get a doubling time in the number >> of route of ~ 6.5 years from my data. I >> do not see a formal doubling time estimate in your presentation, >> but you must have estimated it or the equivalent, to get >> your power law projections, so I would be curious to hear what it is. >> I don't see it as being too much different from your graphs. >> >> 182,000 to 6 million routes is 5.0 doublings, which means that I >> would predict that the system would saturate >> (without artificial constraints) in 33 years, and would reach 1 >> million routes in about 2.46 doublings, or >> ~ 16 years, or 2022. If you assume a doubling time of 5 years (which >> is not supported by the data, but let's >> assume things speed up to be conservative), we get saturation in 20 >> years, and 1 million routes in 12.3 years, >> or 2018. >> >> Note that if you can get a factor of 2 now by defragmenting the >> address space, that adds 1 doubling time (~ 6 years or more) to all >> of these estimates. Note also that you are assuming that most routes >> are doubled in v4 and v6, so that costs you a doubling time if there >> is no defragmentation. Let's assume that that is true, and that there >> is no defragmentation (to be conservative), I get and 1 million >> routes in 9.5 years, or late 2016. If (more reasonably, and more in >> line with your estimates), you assume a 50 % defragmentation >> of the IPv6 address space, and otherwise a sharing of space between >> v4 and v6 (i.e., assuming that every path >> is represented in both address spaces), then you get an address space >> predictor of (1.5 x 2^(# doublings)), or >> 1 million routes in 1.87 doubling times, or 12 years. (Hopefully >> IPv4 growth would actually start to slow at >> some point in this future, so I regard this as a pretty conservative >> estimate.) >> > > You raise an interesting question that i suspect ARIN will not > address, > should multi-homers only get one slot in the global routing table > (i.e. 1* /48) or multiple slots to allow for traffic engineering. My > predictions certainly assume multiple slots, and would be less > agressive > If there was only one slot. This would make the IPv6 table as > large as > the number of ASes in the system which as you point out is linear not > quadratic. :-), but this also does not solve the traffic engineering > problem. Is there any prospect that TE will become unnecessary ? > >> So, I would estimate that 1 million external routes (with no >> artificial constraints) should be achieved somewhere in the 2016 to >> 2022 time frame, and saturation somewhere around 2030 to 2040. (For >> saturation, you clearly also >> have to include an estimate of global economic growth in the next few >> decades, which would take us way >> off into the weeds.) >> >> Of course, I understand from your presentation that you get that >> number by including internal routes, so >> let's look at them too. >> >>> >>> The next question is translating number of routes into RIB size FIB >>> size, >>> CPU speed, etc... Geoff Hustom has done some studies in this >>> area... >>> >>> Take a look at the slides from GROW at IETF 65: >>> >>> http://www3.ietf.org/proceedings/06mar/slides/grow-1.pdf >>> http://www3.ietf.org/proceedings/06mar/slides/grow-0.pdf >>> http://www3.ietf.org/proceedings/06mar/slides/grow-3.pdf >>> >>> My projections are covered in the middle link. >>> >> >> OK, 2013 is 7 years from now, so let's look at your 7 year >> predictions. >> >> For ease of discussion, I will reproduce these here, rounded off : >> >> IPv4 routes : 339,000 >> Projected IPv6 : 237,000 >> >> Projected internal IPv4 (low) : 49,000 >> Projected internal IPv4 (high): 360,000 >> >> Projected internal IPv6 (low) : 132,000 >> Projected internal IPv6 (high): 404,000 >> >> Total External : 576,000 ( 41 % are IPv6) >> Total Internal (low) : 181,000 >> Total Internal (high) : 764,000 >> >> Totals (low) : 825,000 ( 29 % are IPv6 external) >> Totals (high) : 1,340,000 ( 18 % are IPv6 external) >> >> >> (Seven years is just a little over one doubling time from the >> present; I >> would predict a total of 576,000 v4 + v6 external routes then, an >> amazing agreement >> for anything back of the envelope.) >> >> So, for the 1.3 million route router you need to buy now, if SHIM6 >> was working today, and >> there were NO IPv6 routes required at all (ok, 1), then you would >> need to buy a 699,000 route >> router just to support IPv4. If you want to support IPv4 plus IPv6 >> (internal only), that's >> 1.1 million routes. >> >> So, I do not see that external IPv6 routing policy is driving your >> router purchases in the 7 year >> time horizon. Please correct me if I am wrong. > > Assume I have to purchase ne routers today. Are the routers I can buy > today big enought to not be upgraded in 7 years. And again in > seven years > time, are the routers I can buy big enough to not need to be > upgraded in 7 > years. Is 7 years a magic number ? I thought that at the larger ISP's there was a natural cascade, where today's core routers are tomorrow's regional routers and continue to move out the edge as they age. Is that no longer done or realistic ? Aren't there other things, like constantly increasing bandwidth usage, that also makes routers obsolete ? > > Yes it is a factor of a bunch of things, and worst offender is IPv4 > the > IPv4 Internet table. But the IPv4 de-aggrgegates for traffic > engineering > are growing at a faster rate than the total IPv4 table. And sure > you can > prevent IPv6 for inheriting this growth by making it commonly accepted > policy that any ASN should only advertise a single aggrgegate to the > Internet table. > > Shim6 might ease this a bit when its available for people who haven't > already adopted BGP based traffic engineering. 8+8 GSE may ease > this a > bit more for people who haven't already adopted BGP based traffic > engineering and need complex traffic engineer capabilities. > Is 8+8 still on the table ? This came up at RIPE, but I thought that the answer was no. > ___Jason > Regards Marshall > From owen at delong.com Fri Apr 28 15:19:53 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Apr 2006 12:19:53 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: References: Message-ID: One of the other key factors in Jason's numbers is the assumption that all the core routers have to carry full v4 and full v6 tables. I suspect this is actually an unlikely scenario. I suspect that, instead, many large ISPs will end up building out v6 infrastructure on parallel routers and that the tables will end up being split between different routers, especially if v6 starts to grow anywhere near the lines Jason indicates. Leaving the current routers running v4 while deploying new stuff to handle the increasing v6 load is an additional cost, but, generally not a prohibitive one in most scenarios I've looked at for large scale deployments. Primary problem is that it is not viable until v6 starts to become a significant portion of the network and/or revenue. Customer-facing routers will probably still need both, but, there are several ways to address this. Most customer facing routers don't have to have full tables, and, for the ones that do, there are several alternatives to the idea of a full routing table for both protocols on one router. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Fri Apr 28 15:39:49 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Apr 2006 12:39:49 -0700 Subject: [ppml] Policy Proposal -- Recommended v6 aggregation practices Message-ID: Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 Policy Proposal Name: Recommended v6 aggregation practices Author name: Owen DeLong email: owen at delong.com telephone: 408-921-6984 organization: DeLong Consulting Proposal Version: 1.0 Submission Date: 28 April, 2006 Proposal type: new Policy term: permanent Policy statement: Add section 6.3.9 to NRPM as follows: 6.3.9 Recommended Practices to Maximize Aggregation 6.3.9.1 Whenever feasible, an organization should make best possible use of provider assigned space. 6.3.9.2 Except in the most extraordinary of circumstances, no ASN should originate more than a single v6 aggregate prefix. Sparse allocation practices should prevent the need for growth-induced additional prefixes in most cases. Non-ISP organizations expanding beyond their reservation should renumber into the larger block if at all possible. 6.3.9.3 In the case of merger or acquisition resulting in a combination of multiple autonomous systems into a single topology and/or routing policy, the organization should strive to either combine the networks into one of the existing prefixes, or, obtain a new larger prefix and renumber. A grace period of up to 3 years should be allowed for this purpose. Rationale: A number of the concerns raised over proposal 2005-1 seem to center around the possibility of routing table growth due to further deaggregation and other forms of v4-like table bloat resulting from PI space. This proposal is an attempt to reduce and/or mitigate those issues to some extent. I have no illusion that this is a panacea, and, I remain convinced that the only truly viable solution is to develop a routing process for IDR which does not use the End System Identifier as the Routing Locator. I also remain uncomfortable with the idea of ARIN getting involved in routing policy. I think this is the purview of the ISPs exchanging the routes in question. However, I think these recommendations are a reasonable compromise towards a pragmatic attempt to address the existing situation until something better can be achieved. Timetable for implementation: Immediately upon BoT Approval Meeting presenter: Owen DeLong END OF TEMPLATE -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Fri Apr 28 15:40:42 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Apr 2006 12:40:42 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: References: Message-ID: <1789414BF9DF5741083626A0@imac-en0.delong.sj.ca.us> Jason, I've submitted a policy proposal to attempt to provide some of the prevention you seek. I hope you will support it. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From william at elan.net Fri Apr 28 15:43:15 2006 From: william at elan.net (william(at)elan.net) Date: Fri, 28 Apr 2006 12:43:15 -0700 (PDT) Subject: [ppml] Policy Proposal -- Recommended v6 aggregation practices In-Reply-To: References: Message-ID: Question: How do you expect ->ARIN<- to implement this? On Fri, 28 Apr 2006, Owen DeLong wrote: > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > Policy Proposal Name: Recommended v6 aggregation practices > Author > name: Owen DeLong > email: owen at delong.com > telephone: 408-921-6984 > organization: DeLong Consulting > Proposal Version: 1.0 > Submission Date: 28 April, 2006 > Proposal type: new > Policy term: permanent > Policy statement: > > Add section 6.3.9 to NRPM as follows: > > 6.3.9 Recommended Practices to Maximize Aggregation > 6.3.9.1 > Whenever feasible, an organization should make best possible > use of provider assigned space. > > 6.3.9.2 > Except in the most extraordinary of circumstances, no ASN should > originate more than a single v6 aggregate prefix. Sparse allocation > practices should prevent the need for growth-induced additional > prefixes in most cases. Non-ISP organizations expanding beyond their > reservation should renumber into the larger block if at all possible. > > 6.3.9.3 > In the case of merger or acquisition resulting in a combination > of multiple autonomous systems into a single topology and/or > routing policy, the organization should strive to either combine > the networks into one of the existing prefixes, or, obtain a > new larger prefix and renumber. A grace period of up to 3 years > should be allowed for this purpose. > > Rationale: > > A number of the concerns raised over proposal 2005-1 seem to center > around the possibility of routing table growth due to further deaggregation > and other forms of v4-like table bloat resulting from PI space. > > This proposal is an attempt to reduce and/or mitigate those issues > to some extent. I have no illusion that this is a panacea, and, I > remain convinced that the only truly viable solution is to develop > a routing process for IDR which does not use the End System Identifier > as the Routing Locator. > > I also remain uncomfortable with the idea of ARIN getting involved > in routing policy. I think this is the purview of the ISPs exchanging > the routes in question. However, I think these recommendations are > a reasonable compromise towards a pragmatic attempt to address the > existing situation until something better can be achieved. > > Timetable for implementation: Immediately upon BoT Approval > Meeting presenter: Owen DeLong > > END OF TEMPLATE From owen at delong.com Fri Apr 28 16:16:38 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Apr 2006 13:16:38 -0700 Subject: [ppml] Policy Proposal -- Recommended v6 aggregation practices In-Reply-To: References: Message-ID: <6420725C7A45AC256F7C7187@imac-en0.delong.sj.ca.us> I expect ARIN to implement it strictly by sticking the words in the NRPM. I do not expect it to be in any way enforceable, as ARIN does not enforce routing policy. However, most of the content of that section of NRPM is unenforceable guidelines, so, I don't see any reason to treat these differently. Owen --On April 28, 2006 12:43:15 PM -0700 "william(at)elan.net" wrote: > > Question: How do you expect ->ARIN<- to implement this? > > On Fri, 28 Apr 2006, Owen DeLong wrote: > >> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 >> >> Policy Proposal Name: Recommended v6 aggregation practices >> Author >> name: Owen DeLong >> email: owen at delong.com >> telephone: 408-921-6984 >> organization: DeLong Consulting >> Proposal Version: 1.0 >> Submission Date: 28 April, 2006 >> Proposal type: new >> Policy term: permanent >> Policy statement: >> >> Add section 6.3.9 to NRPM as follows: >> >> 6.3.9 Recommended Practices to Maximize Aggregation >> 6.3.9.1 >> Whenever feasible, an organization should make best possible >> use of provider assigned space. >> >> 6.3.9.2 >> Except in the most extraordinary of circumstances, no ASN should >> originate more than a single v6 aggregate prefix. Sparse allocation >> practices should prevent the need for growth-induced additional >> prefixes in most cases. Non-ISP organizations expanding beyond their >> reservation should renumber into the larger block if at all possible. >> >> 6.3.9.3 >> In the case of merger or acquisition resulting in a combination >> of multiple autonomous systems into a single topology and/or >> routing policy, the organization should strive to either combine >> the networks into one of the existing prefixes, or, obtain a >> new larger prefix and renumber. A grace period of up to 3 years >> should be allowed for this purpose. >> >> Rationale: >> >> A number of the concerns raised over proposal 2005-1 seem to center >> around the possibility of routing table growth due to further >> deaggregation and other forms of v4-like table bloat resulting from PI >> space. >> >> This proposal is an attempt to reduce and/or mitigate those issues >> to some extent. I have no illusion that this is a panacea, and, I >> remain convinced that the only truly viable solution is to develop >> a routing process for IDR which does not use the End System Identifier >> as the Routing Locator. >> >> I also remain uncomfortable with the idea of ARIN getting involved >> in routing policy. I think this is the purview of the ISPs exchanging >> the routes in question. However, I think these recommendations are >> a reasonable compromise towards a pragmatic attempt to address the >> existing situation until something better can be achieved. >> >> Timetable for implementation: Immediately upon BoT Approval >> Meeting presenter: Owen DeLong >> >> END OF TEMPLATE -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From woody at pch.net Fri Apr 28 16:21:16 2006 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Apr 2006 13:21:16 -0700 (PDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D0E@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D0E@wava00s2ke2k01.corp.pvt> Message-ID: > Given the pro's and con's of addressing this issue at ARIN/NANOG vs IETF. Who supports taking this to IETF and who supports taking this to ARIN/NANOG? > I ask this so that I know which way to push this. It appears there are a few of us willing to work together in order to try and find a resolution. However, I would really like community input on where they would like this resolution "created/pushed". I think the IETF is the best home for the document. I think that NANOG is neither a home for documents, nor a place for creating them. I think that ARIN is a place where we can create documents and export them. I think that we may have trouble reaching consensus though, in which case it may not be clear what to submit. -Bill From woody at pch.net Fri Apr 28 16:41:21 2006 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Apr 2006 13:41:21 -0700 (PDT) Subject: [ppml] Policy Proposal -- Recommended v6 aggregation practices In-Reply-To: References: Message-ID: On Fri, 28 Apr 2006, Owen DeLong wrote: > Except in the most extraordinary of circumstances, no ASN should > originate more than a single v6 aggregate prefix. Not arguing the good or bad of it, but this does take an eyeball perspective as its core premise. I think a lot of content people might find it a little inapplicable to their universe. Furthermore, I'm not very comfortable with these sort of recommendations going into ARIN policy. They really seem like either IETF work or simply the sort of positions that companies have always tried to convince each other of when trying to gain leverage in the marketplace. -Bill From woody at pch.net Fri Apr 28 16:50:26 2006 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Apr 2006 13:50:26 -0700 (PDT) Subject: [ppml] Policy Proposal -- Recommended v6 aggregation practices In-Reply-To: References: Message-ID: > On Fri, 28 Apr 2006, Owen DeLong wrote: > > Except in the most extraordinary of circumstances, no ASN should > > originate more than a single v6 aggregate prefix. > > Not arguing the good or bad of it, but this does take an eyeball > perspective as its core premise. I think a lot of content people might > find it a little inapplicable to their universe. Also, this assumes that _all_ multihoming is done with PI space. I would, of course, much prefer to see that be the case, but you might want to make it explicit. -Bill From marla_azinger at eli.net Fri Apr 28 17:00:13 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 28 Apr 2006 14:00:13 -0700 Subject: [ppml] Policy Proposal -- Recommended v6 aggregation practices Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D15@wava00s2ke2k01.corp.pvt> I dont support this proposal and it is completly unbalanced. 2005-1 is a positive step. But this just slams the door on other users that need to mutihome to support their customers. This is a step in the wrong direction. Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Bill Woodcock Sent: Friday, April 28, 2006 1:50 PM To: Owen DeLong Cc: ppml at arin.net; policy at arin.net Subject: Re: [ppml] Policy Proposal -- Recommended v6 aggregation practices > On Fri, 28 Apr 2006, Owen DeLong wrote: > > Except in the most extraordinary of circumstances, no ASN should > > originate more than a single v6 aggregate prefix. > > Not arguing the good or bad of it, but this does take an eyeball > perspective as its core premise. I think a lot of content people might > find it a little inapplicable to their universe. Also, this assumes that _all_ multihoming is done with PI space. I would, of course, much prefer to see that be the case, but you might want to make it explicit. -Bill _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From michel at arneill-py.sacramento.ca.us Fri Apr 28 23:55:38 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 28 Apr 2006 20:55:38 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: Marla, > Marla Azinger wrote: > However, I also believe policy can change. So do I, otherwise I would not support 2005-1. > So why shouldnt this policy just be motivation to make shim6 work? Keep in mind that I _do_ support this policy, the short answer is that it's wishful thinking too little too late, read below for full rationale. The way I see 2005-1 is as follows: 1. The decision to allocate PI is an engineering decision, not a policy one. ARIN is stepping on the IETF toes doing this. 2. The IETF has failed to deliver an IPv6 multihoming solution for 11+ years running, which is precisely why ARIN has put 2005-1 in last call. 3. There is risk involved with 2005-1, but this risk is manageable. I don't believe PI prefixes handed out by 2005-1 can ever be reclaimed, but the policy can be changed back as you pointed out. To those who scream about early adopters getting an unfair edge, I say this: early adopters take risk and spend money late adopters don't; IPv6 desperately needs early adopters, having a PI block does not pay for the risk and the spending, shut up. Besides, many organizations already have a PI block, and those who don't can easily lie about their needs and become a LIR if they want one bad. 4. Regardless of the technical merits, 2005-1 is good for at least one thing: it sends a strong message to the IETF saying in substance "In case you have not noticed, it's about time to stick your head out of somewhere and actually deliver something that could be accepted by both the op community and the end customer". So far, so good. But now here are the catches: >> So why shouldnt this policy just be motivation to make shim6 work? > it sends a strong message to the IETF saying in substance: > In case you have not noticed, it's about time to stick your > head out of somewhere and actually deliver something Catch #1: the reasons shim6 has been rejected is because many technically enabled persons have assessed that it can _not_ be fixed (whatever it means by their criteria) by fine-tuning it. Shim6 has 4 major issues: a) It's not finalized yet. b) No real-world implementation. c) TE nightmare. d) Requires multiple addresses per host. Let's say a) and b) could eventually be solved. Remains to be seem though. c) and d) are structural design issues that are deliberate design choices. No changes to shim6 can make operators happy with TE issues neither could they convince enterprises that multiple PA addresses per host is a supportable solution. Catch #2: the IETF has noticed; they do not need your reminder neither motivation. I personally know, have met several times, and have a profound respect for many of the individuals involved there. I personally think that two or three are completely full of it and I disagree with score of others; that being said, and contrary to some conspiracy theories, and acknowledging that the IETF has some shortcomings and limitations, the fact of the matter is that the IETF is not this evil entity that tries to screw ARIN or somebody else. As said earlier, the IETF has failed to deliver an IPv6 multihoming solution but it's certainly not because they have not tried. > So why shouldnt this policy just be motivation to make shim6 work? You're sending the wrong message to the IETF. Shim6 is not economically and politically deployable given the current conditions. I can't speak for Mike O'Dell WRT GSE, but I can speak for MHAP and it's not economically and politically deployable given the current conditions either. The way out of this mess is a BGP replacement that could handle large-scale PI. Michel. From bmanning at vacation.karoshi.com Sat Apr 29 01:30:18 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 29 Apr 2006 05:30:18 +0000 Subject: [ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal In-Reply-To: <200604271841.k3RIesT4008697@cichlid.raleigh.ibm.com> References: <200604271841.k3RIesT4008697@cichlid.raleigh.ibm.com> Message-ID: <20060429053018.GA3291@vacation.karoshi.com.> > Having said that, ULA space is different, precisely because it is not > intended to be routed publically, so IMO it's much less clear that the > same amount of leverage is needed/appropriate. Please clarify "routed publically" please. it seems roughly akin to the prohibition on RFC1918 space from showing up on the "public Internet" and we -KNOW- that RFC1918 space is seen in the Internet, despite the RFC prohibition. In my view, public routing is anything that crosses my AS boundary into someone elses ASN. Which kind of leaves ULA space as space the be hidden behind a NAT device. --bill > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml