From bicknell at ufp.org Tue May 1 08:45:04 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 1 May 2007 08:45:04 -0400 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: Message-ID: <20070501124504.GA17437@ussenterprise.ufp.org> In a message written on Mon, Apr 30, 2007 at 01:26:25PM -0700, Owen DeLong wrote: > 4. If the review shows that existing usage is substantially > not in compliance with current allocation and/or assignment policies, the > organization shall return resources as required to bring them into > compliance. If an organization holds multiple ARIN delegations, they I'm going to raise the objection I think staff will raise, what is "substantially not in compliance"? I think this goes to two different areas, procedural and utilization. In the procedural camp we have things like failing to maintain records (no SWIP's, no RWHOIS, perhaps not even any real written documentation, or even giving out /24's to every customer regardless of actual need). I would think on any procedural violation the right thing to do would be a "probation" period where the holder can rectify the situation, and quite frankly, if they can't comply with the documentation aspects I think all of their space should be pulled. Utilization is sticker, and I suggest it needs to be a high and low watermark sort of arrangement. Right now (for ISP's) the numbers are you get a 6 month supply, and you need 80% for more space. So what if you get a six month supply and then your business experiences some issue so that a year later you're only at 60% utilization? Is that "substantially not in compliance"? So what about a definition like: Any block less than 25% utilized is substantially not in compliance. I think that works for ISP's, who must show 80% to get a new block, and then only get a 6 month supply, and also for end users, who must show 25% day one, with 50% utilization projection for one year. I do support the concept of the policy, and I think what you've put together is pretty reasonable. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From michael.dillon at bt.com Tue May 1 10:28:35 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 1 May 2007 15:28:35 +0100 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: <20070501124504.GA17437@ussenterprise.ufp.org> References: <20070501124504.GA17437@ussenterprise.ufp.org> Message-ID: > of actual need). I would think on any procedural violation the > right thing to do would be a "probation" period where the holder > can rectify the situation, and quite frankly, if they can't comply > with the documentation aspects I think all of their space should > be pulled. You started out right but then went astray just like the original authors. We are not police officers. We are not peacekeeping forces in a war zone. We are not high-school principals. We are not even the Internet's HR department. We are just a bunch of people who share fate through a shared resource which happens to be limited in nature. Language like "probation" is inappropriate for ARIN policy as is the attitudes that lead to including things like "all of their space should be pulled". Yes, it would be good for ARIN to have some powers to audit usage. But this is not the way to go about it. First of all, any ARIN actions around auditing should start with the issue of records and reporting. I'm not suggesting that we go the way of NANPA with regular usage and runout reports, but that if we want ARIN to get involved in auditing usage, the first step is to *HELP* (not force) the orgs to do their own internal auditing and reporting. The first step is for ARIN to develop and publish some standards for recordkeeping. After that, perhaps the problems will go away. Or maybe not and we will need to go to the next step where ARIN can demand to review the said records and audit them for accuracy. You cannot audit records which do not exist and you cannot audit records which are in disarray. Given the number of telecom companies who struggle with keeping track of circuits, where there is a monthly dollar penalty for bad recordkeeping, I don't expect ARIN to find auditing very easy. If ARIN is going to audit, we have to make sure it can be done relatively cheaply. As for what is to be done when records are audited and found to be defficient, pulling *ALL* address space is the wrong thing. Such language has no place in ARIN policy. Possibly there is a place for pulling unjustified address space, but that *MUST* be done in a reasonable way with renumbering transition periods, etc. In fact, after it is determined that an org cannot demonstrate technical justification for their existing address space, the right action for ARIN to take is dependent on the state of their recordkeeping. If bad records are the reason why they cannot demonstrate justification, then ARIN should start by ordering them to bring their records into order, and give them time and assistance to do so. Part of that assistance is the above-mentioned standards for recordkeeping. If the org has good enough records but just lack the justification, then ARIN should order a remediation plan. This will also give the org ample time to deal with any issues surrounding renumbering, but it also allows the org to do things like acquire new customers and thus acquire the technical justification that they need. They could buy another ISP and renumber all their customers and give back the other ISP's addresses instead of their own. This is like when a court orders an accounting firm to run a business's financial affairs rather than ordering a bankruptcy. I use this analogy specifically because I believe that ARIN's role here has to be in helping an org reach compliance, not in punishing an org or pulling the rug out from under them. The fact is that for many years (and maybe still to this day) there has not been any accepted description of what constitutes technical justification for IPv4 address allocations/assignments. In the absence of a clear description, thousands of engineers and managers have built up networks and businesses thinking that they were following ARIN guidelines in good faith. You simply cannot turn 180 degrees and attack these people who have been acting in good faith. If it means that we run into the brick wall of IPv4 exhaustion, then so be it. That is the outcome that all of us created by not acting sooner to clarify what technical justification means. Staving off exhaustion for some orgs is not sufficient justification for attacking other orgs who have been acting in good faith, regardless of whose records are in good order and whose aren't. This policy proposal is a bad, bad thing and I hope that it is withdrawn before it ever reaches the next ARIN meeting. Wordsmithing is not the answer. A completely different take on the issue is needed and we need to begin with the right attitudes. Remember, ARIN's charter includes education but does not include enforcement. I believe that a serious effort to develop and publish standards for recordkeeping as well as defining in great detail, what is technical justification and what is not, will go a long way to reducing IPv4 address consumption without punitive policies. It will do this in two ways. First, I believe that the majority of ISPs have addresses that they could reuse if they only knew where they are. Helping everyone find their internal wastage and inefficiency, will lead to smaller requests for new addresses. How many of your customers with a /28 assignment are actually running PAT on their gateways? And the second way is that the publicity surrounding this effort will raise awareness of IPv4 exhaustion and drive people towards demanding IPv6 services. Remember, everything that ARIN does surrounding IPv4 exhaustion will attract great media attention. Choose your policy proposals wisely. --Michael Dillon From m.hertrick at neovera.com Tue May 1 10:43:07 2007 From: m.hertrick at neovera.com (Michael Hertrick) Date: Tue, 01 May 2007 10:43:07 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: <4635E419.1030801@neovera.com> <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> Message-ID: <463751FB.4060507@neovera.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I like what I've been reading, too. I like the idea of using LIR in lieu of ISP. Thanks, ~Mike. Edward Lewis wrote: > Having been hyperactive this past week on the mailing list I waited > to jump in on this" - hoping to read a post with the same sentiment > that I have. > > And I have. > > At 18:19 -0400 4/30/07, Matt Pounsett wrote: > >> I agree with much of what you're saying here and in the rest of your >> email, but I don't completely agree with where you end up. All ASPs, >> web hosting companies, and colo providers are not ISPs in the sense >> that the term is used in the NRPM. I think it's important to look at >> the intent of the policy in order to find a better definition for >> "ISP" or to find a different word to use. > > Metoo. We aren't trying to define what an ISP is, we are trying to > distinguish between organizations in the context of the policies of > ARIN. So, the arguments that we all are ISPs are (arguably) right, > but what we really need is to distinguish between organizations > getting resources for themselves and organizations getting resources > for their "customers." > >> model and should be classed as ISPs. I think Steven Sprunk is on the >> right track, that we should perhaps be looking at using a new term >> (such as LIR) for these non-end-user organizations. That would go a >> long way to helping clear up confusion. > > At first I disagreed with the use of the term "LIR," but what Matt > adds on here makes me think that that might be the right thing to do. > Historically ARIN has used ISP and "the other" RIRs use LIR and I > always thought that it was just a terminology thing. But it is true > - we aren't distinguishing between ISPs and ASPs, rather LIRs from > end-users of the resources. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGN1H7cJVdtfpkLb8RAhPPAJ0bqInpDDM18dDCkuD0yE6LAKXGVgCfbLaD iwKi/IH72DU6IgtMyOKMEd8= =zItd -----END PGP SIGNATURE----- From leo.vegoda at icann.org Tue May 1 11:02:15 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 1 May 2007 17:02:15 +0200 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> References: <4635E419.1030801@neovera.com> <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> Message-ID: <37D65F5B-657F-4607-94F1-D71072FFBD9E@icann.org> On 1 May 2007, at 12:19am, Matt Pounsett wrote: [...] > The defining characteristic of an "ISP" as referenced in the NRPM is > that the organization reassigns address space to organizations other > than itself. Is that definition adequate for today? Does the definition need to be broadened to meet the needs of anyone with an ongoing need for address space allocations? Regards, -- Leo Vegoda IANA Numbers Liaison From stephen at sprunk.org Tue May 1 11:23:34 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 1 May 2007 10:23:34 -0500 Subject: [ppml] Revised Policy Proposal Resource Reclamation References: <20070501124504.GA17437@ussenterprise.ufp.org> Message-ID: <00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> Thus spake "Leo Bicknell" > In a message written on Mon, Apr 30, 2007 at 01:26:25PM -0700, Owen DeLong > wrote: >> 4. If the review shows that existing usage is substantially >> not in compliance with current allocation and/or assignment >> policies, the organization shall return resources as required >> to bring them into compliance. > > I'm going to raise the objection I think staff will raise, what is > "substantially not in compliance"? ... > Utilization is sticker, and I suggest it needs to be a high and > low watermark sort of arrangement. Right now (for ISP's) the > numbers are you get a 6 month supply, and you need 80% for > more space. So what if you get a six month supply and then > your business experiences some issue so that a year later > you're only at 60% utilization? Is that "substantially not in > compliance"? That's close enough to compliant for me. In such a case, they'd probably manage to hit 80% before the grace period was over anyways, making revocation moot. At most ARIN could take a quarter of their space, and they'd get it back in a few months. It just wouldn't make sense to bother. As a hypothetical example, say IPv4 exhaustion comes and in response we pass a policy saying that NAT is now mandatory for all customers and any assignment larger than a /32 has to be justified. We would expect ARIN to initiate a review of anyone with more than a minimum-size allocation. If you were still issuing /24s to every customer regardless of need, as many ISPs do today, they'd whack you over the head and give you 6 months (or a longer, reasonable period if requested) to clean up your act. More likely, say we eventually decide -- and counsel agrees -- that policy applies to folks with legacy assignments. ARIN would then review everyone with such and apply the "if you applied for space today, what would we give you" standard. If the org had significantly more than that amount, e.g. certain universities with a /8 who only really need a /14 or so, they'd get whacked. Ditto for any org whose space doesn't show up in the global routing table and who doesn't respond to all reasonable attempts by ARIN to contact them; the presumption would be the space is no longer in use, not compliant with current policy, and could be reclaimed. There's a lot of low-hanging fruit out there, even under existing policy. If we ever get to the point an evil ARIN is descending on ISPs every year and auditing them like the IRS, Owen and I will be first in line to propose taking this policy back. However, my impressions are that the staff finds that idea as distasteful as we do and that they aren't interested in revocations unless a given situation is so obviously b0rked that their conscience leaves them no choice. We're not out to get people who are acting in good faith and getting reasonably close to the target that current policy specifies, even if they make mistakes along the way. > I do support the concept of the policy, and I think what you've > put together is pretty reasonable. Thanks. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From owen at delong.com Tue May 1 11:48:22 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 1 May 2007 08:48:22 -0700 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <463751FB.4060507@neovera.com> References: <4635E419.1030801@neovera.com> <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> <463751FB.4060507@neovera.com> Message-ID: <848F083E-AE1E-43E9-9E62-C22629B1D858@delong.com> On May 1, 2007, at 7:43 AM, Michael Hertrick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I like what I've been reading, too. I like the idea of using LIR in > lieu of ISP. > > Thanks, > ~Mike. So do I. However, doing that requires a policy proposal. I'm actively working on three policy proposals at this point. Two of which have been submitted and one which is still in the preparation phase. My intent was to help Leslie get an idea of group consensus on the meaning of existing policy. Anyone who wishes to make this change is certainly welcome (I'll even say encouraged) to submit a proposal to accomplish the above stated goal. I don't currently have the cycles to do it. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From rich at nic.umass.edu Tue May 1 12:01:12 2007 From: rich at nic.umass.edu (Rich Emmings) Date: Tue, 1 May 2007 12:01:12 -0400 (EDT) Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: <00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> References: <20070501124504.GA17437@ussenterprise.ufp.org> <00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> Message-ID: On Tue, 1 May 2007, Stephen Sprunk wrote: > More likely, say we eventually decide -- and counsel agrees -- that policy > applies to folks with legacy assignments. ARIN would then review everyone > with such and apply the "if you applied for space today, what would we give > you" standard. If the org had significantly more than that amount, e.g. > certain universities with a /8 who only really need a /14 or so, they'd get > whacked. Ditto for any org whose space doesn't show up in the global > routing table and who doesn't respond to all reasonable attempts by ARIN to > contact them; the presumption would be the space is no longer in use, not > compliant with current policy, and could be reclaimed. 1) Legacy IP Space assignments were not assigned by ARIN -- do they have control over it, especially, if no RSA was signed (see #3) Likely, in order to give all the RIR's a square shake, it'd have to go back to IANA not ARIN. 2) ARIN provides globally unique numbers without regard to routing, given justifiable need. That it shows up in the routing table is not a requirement, and they explicitly say the space you are getting is not guaranteed routable. In other words, they are a number registry. 3) Universities with a /8 (or other size) who have not asked for space recently, may be worth approaching for reclaimation; those that have added space to their initial allocations, have probably done their justifications recently. Those who ignore ARIN may be legally justifed in doing so -- they did not get their space from ARIN, so have not agreed to the RSA. Does ARIN have legal control over their space? If I were them, I'd legally argue no, and by the time it gets settled, it'd probably moot. (not that I don't question why some early allocations continue to have huge amounts of space, not only /8's. but also multiple /16's and /24's) FWIW, My last count was 12 assigned /8's that weren't in the global routing tables. If we pushed those folks, they'd just announce some small prefix somewhere, and it'd be announced. That the rest of their network is FW'd off from you is their business. Just because they don't announce it today, doesn't mean they aren't entitled to the space. Plus, they probably never signed an ARIN RSA, a few are international, government or multi-national, so ARIN's legal ability to smack down may be a long and rocky road. From owen at delong.com Tue May 1 12:51:28 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 1 May 2007 09:51:28 -0700 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: <20070501124504.GA17437@ussenterprise.ufp.org> <00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> Message-ID: On May 1, 2007, at 9:01 AM, Rich Emmings wrote: > On Tue, 1 May 2007, Stephen Sprunk wrote: > >> More likely, say we eventually decide -- and counsel agrees -- >> that policy >> applies to folks with legacy assignments. ARIN would then review >> everyone >> with such and apply the "if you applied for space today, what >> would we give >> you" standard. If the org had significantly more than that >> amount, e.g. >> certain universities with a /8 who only really need a /14 or so, >> they'd get >> whacked. Ditto for any org whose space doesn't show up in the global >> routing table and who doesn't respond to all reasonable attempts >> by ARIN to >> contact them; the presumption would be the space is no longer in >> use, not >> compliant with current policy, and could be reclaimed. > > 1) Legacy IP Space assignments were not assigned by ARIN -- do they > have > control over it, especially, if no RSA was signed (see #3) Likely, > in order > to give all the RIR's a square shake, it'd have to go back to IANA > not ARIN. > My opinion is that no RIR has any authority to revoke legacy space absent the holder voluntarily signing an RSA. However, in terms of a fair shake, the RIRs have actually divided up the legacy space geographically as well as is possible, so, there would not be a need for it to go back to IANA. It can be returned to the appropriate RIR. > 2) ARIN provides globally unique numbers without regard to routing, > given > justifiable need. That it shows up in the routing table is not a > requirement, and they explicitly say the space you are getting is not > guaranteed routable. In other words, they are a number registry. > Right. Hence the "AND" term for requiring that both the space is unrouted and that the POC is unreachable. If both of these conditions are met, it is not unreasonable to presume that the addresses have been abandoned. > 3) Universities with a /8 (or other size) who have not asked for space > recently, may be worth approaching for reclaimation; those that > have added > space to their initial allocations, have probably done their > justifications > recently. Those who ignore ARIN may be legally justifed in doing > so -- they > did not get their space from ARIN, so have not agreed to the RSA. > Does ARIN > have legal control over their space? If I were them, I'd legally > argue no, > and by the time it gets settled, it'd probably moot. (not that I > don't > question why some early allocations continue to have huge amounts > of space, > not only /8's. but also multiple /16's and /24's) > Agreed. Further, I'd like to point out that this is not the intent of the policy proposal at hand. The intent is to give ARIN the tools to audit compliance and reclaim space subject to an RSA which does not meet ARIN standards. > > > FWIW, My last count was 12 assigned /8's that weren't in the global > routing > tables. If we pushed those folks, they'd just announce some small > prefix > somewhere, and it'd be announced. That the rest of their network > is FW'd > off from you is their business. Just because they don't announce > it today, > doesn't mean they aren't entitled to the space. Plus, they > probably never > signed an ARIN RSA, a few are international, government or multi- > national, > so ARIN's legal ability to smack down may be a long and rocky road. Noone is proposing revocation based solely on non-routed nature. However, unrouted and with unreachable POC tends to lead to a reasonable presumption of abandonment. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From stephen at sprunk.org Tue May 1 13:18:40 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 1 May 2007 12:18:40 -0500 Subject: [ppml] Revised Policy Proposal Resource Reclamation References: <20070501124504.GA17437@ussenterprise.ufp.org><00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> Message-ID: <015001c78c17$3d3490a0$4a3816ac@atlanta.polycom.com> Thus spake "Rich Emmings" > On Tue, 1 May 2007, Stephen Sprunk wrote: >> More likely, say we eventually decide -- and counsel agrees -- >> that policy applies to folks with legacy assignments. ARIN >> would then review everyone with such and apply the "if you >> applied for space today, what would we give you" standard. If >> the org had significantly more than that amount, e.g. certain >> universities with a /8 who only really need a /14 or so, they'd >> get whacked. Ditto for any org whose space doesn't show up >> in the global routing table and who doesn't respond to all >> reasonable attempts by ARIN to contact them; the >> presumption would be the space is no longer in use, not >> compliant with current policy, and could be reclaimed. > > 1) Legacy IP Space assignments were not assigned by ARIN > -- do they have control over it, especially, if no RSA was signed > (see #3) Likely, in order to give all the RIR's a square shake, > it'd have to go back to IANA not ARIN. All the legacy space was transferred to an appropriate RIR for maintenance a while back. If that space was reclaimed, it's logical to assume that it'd stay with the RIR that it was transferred to by IANA. Unless, of course, IANA says something to the contrary. > 2) ARIN provides globally unique numbers without regard to > routing, given justifiable need. That it shows up in the routing > table is not a requirement, and they explicitly say the space you > are getting is not guaranteed routable. In other words, they are > a number registry. All true, but if the space _does_ show up in the routing table, that creates the presumption that it's in use. If ARIN could contact the org and they justified private use, that's within current policy as well. Orgs are encouraged to use RFC1918 space on private networks, but they can get direct assignments for private use if they insist. That may change as we get closer to (or past) exhaustion, though. > 3) Universities with a /8 (or other size) who have not asked for > space recently, may be worth approaching for reclaimation; IIRC, at least one has done so voluntarily. Others might be convinced if ARIN asked nicely. Still others might be forced to do so if the community agrees that's fair and necessary -- and counsel can figure out how to make it stick. > those that have added space to their initial allocations, have > probably done their justifications recently. And if so, we'll look elsewhere. > Those who ignore ARIN may be legally justifed in doing so -- > they did not get their space from ARIN, so have not agreed to > the RSA. Does ARIN have legal control over their space? If I > were them, I'd legally argue no, and by the time it gets settled, > it'd probably moot. (not that I don't question why some early > allocations continue to have huge amounts of space, not only > /8's. but also multiple /16's and /24's) OTOH, since there's no RSA signed and no fees paid, one could argue that ARIN has no obligation to keep maintaining that space or to refrain from issuing it to someone else. I can legally refuse to pay to register my car and sign the papers, but if I don't, the state can reuse my license plate number; they're only obligated to keep my registration unique if I pay them. I'm sure others can come up with equally-flawed analogies to support arguments either way :) > FWIW, My last count was 12 assigned /8's that weren't in the > global routing tables. If we pushed those folks, they'd just > announce some small prefix somewhere, and it'd be announced. > That the rest of their network is FW'd off from you is their > business. Just because they don't announce it today, doesn't > mean they aren't entitled to the space. Plus, they probably never > signed an ARIN RSA, a few are international, government or > multi-national, so ARIN's legal ability to smack down may be a > long and rocky road. I agree that there's lots of problems to be settled with how we treat legacy space. This proposal, however, doesn't attempt to address that; I was merely using it as a hypothetical case of how a significant policy change could make reclamation useful. If/when someone floats a proposal on the exact status of legacy space, Mr. Ryan will have his work cut out for him. Until then, conventional thinking is that it can't be revoked but does count in a justification review, e.g. it could be used as the basis for revoking non-legacy resources if the org is not within policy overall. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From rich at nic.umass.edu Tue May 1 13:44:04 2007 From: rich at nic.umass.edu (Rich Emmings) Date: Tue, 1 May 2007 13:44:04 -0400 (EDT) Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: <20070501124504.GA17437@ussenterprise.ufp.org> <00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> Message-ID: Even if both conditions were met, I'm not sure ARIN has authority, as it's legacy space and no RSA exists. A random email from a business I don't do business with demanding something usually gets filed in my SPAM folder. I'd hope anyone with a large number asset at least knows who/what ARIN is, but it's not impossible for someone ARIN familiar to leave a given shop, and leave behind those clueless. Short version: I can't see the AND being a sure enough condition, because the number might be ignoring ARIN, and has no business relationship with ARIN, barring some sort of global policy demanding you register with your local RIR and sign a RSA. Are there abandon assets out there. I'd say it's a sure bet. If it's an ARIN asset, then ARIN does have authority over it. Otherwise, I think only IANA can revoke. Same for underutilized assets. It's messy, but it can always be made messier. On Tue, 1 May 2007, Owen DeLong wrote: > Right. Hence the "AND" term for requiring that both the space is unrouted > and that the POC is unreachable. If both of these conditions are met, it > is not unreasonable to presume that the addresses have been abandoned. From tme at multicasttech.com Tue May 1 13:46:09 2007 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 1 May 2007 13:46:09 -0400 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: <015001c78c17$3d3490a0$4a3816ac@atlanta.polycom.com> References: <20070501124504.GA17437@ussenterprise.ufp.org><00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> <015001c78c17$3d3490a0$4a3816ac@atlanta.polycom.com> Message-ID: Hello On May 1, 2007, at 1:18 PM, Stephen Sprunk wrote: > All true, but if the space _does_ show up in the routing table, > that creates > the presumption that it's in use. If ARIN could contact the org > and they > justified private use, that's within current policy as well. Orgs are > encouraged to use RFC1918 space on private networks, but they can > get direct > assignments for private use if they insist. That may change as we get > closer to (or past) exhaustion, though. > Is there an enumeration of the amount of space that is assigned for private use ? Regards Marshall >> 3) Universities with a /8 (or other size) who have not asked for >> space recently, may be worth approaching for reclaimation; > > IIRC, at least one has done so voluntarily. Others might be > convinced if > ARIN asked nicely. Still others might be forced to do so if the > community > agrees that's fair and necessary -- and counsel can figure out how > to make > it stick. > >> those that have added space to their initial allocations, have >> probably done their justifications recently. > > And if so, we'll look elsewhere. > >> Those who ignore ARIN may be legally justifed in doing so -- >> they did not get their space from ARIN, so have not agreed to >> the RSA. Does ARIN have legal control over their space? If I >> were them, I'd legally argue no, and by the time it gets settled, >> it'd probably moot. (not that I don't question why some early >> allocations continue to have huge amounts of space, not only >> /8's. but also multiple /16's and /24's) > > OTOH, since there's no RSA signed and no fees paid, one could argue > that > ARIN has no obligation to keep maintaining that space or to refrain > from > issuing it to someone else. > > I can legally refuse to pay to register my car and sign the papers, > but if I > don't, the state can reuse my license plate number; they're only > obligated > to keep my registration unique if I pay them. I'm sure others can > come up > with equally-flawed analogies to support arguments either way :) > >> FWIW, My last count was 12 assigned /8's that weren't in the >> global routing tables. If we pushed those folks, they'd just >> announce some small prefix somewhere, and it'd be announced. >> That the rest of their network is FW'd off from you is their >> business. Just because they don't announce it today, doesn't >> mean they aren't entitled to the space. Plus, they probably never >> signed an ARIN RSA, a few are international, government or >> multi-national, so ARIN's legal ability to smack down may be a >> long and rocky road. > > I agree that there's lots of problems to be settled with how we > treat legacy > space. This proposal, however, doesn't attempt to address that; I was > merely using it as a hypothetical case of how a significant policy > change > could make reclamation useful. > > If/when someone floats a proposal on the exact status of legacy > space, Mr. > Ryan will have his work cut out for him. Until then, conventional > thinking > is that it can't be revoked but does count in a justification > review, e.g. > it could be used as the basis for revoking non-legacy resources if > the org > is not within policy overall. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From rich at nic.umass.edu Tue May 1 14:01:10 2007 From: rich at nic.umass.edu (Rich Emmings) Date: Tue, 1 May 2007 14:01:10 -0400 (EDT) Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: <20070501124504.GA17437@ussenterprise.ufp.org><00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> <015001c78c17$3d3490a0$4a3816ac@atlanta.polycom.com> Message-ID: I estimate it 12 classical "A"s that are in iana's listing, but that I don't typically find in the routing tables. I don't chase the B's. The A's are multinationals, government, businesses and military (multiple countries.) A RFC1918 network consists of non-globally unique addresses. A network that doesn't appear in the global routing tables is still globally unique. There have have been bogon routes that leak into the global tables from time to time, which are not normally found there. The RFC1918 numbers provide the most glaring examples, but others that have used space other than RFC1918 occasionally leak one now and then. I believe recently, someone had a comment about seeing 128.0.0.0/2 in a routing table at some random router on the net. Edu-wise, only MIT and MERIT (a state wide network) are holding (and routing) /8's. MERIT is large. From recollection, MIT had some /16's a while back that I no longer see, so perhaps they turned in some space. On Tue, 1 May 2007, Marshall Eubanks wrote: > Hello > > On May 1, 2007, at 1:18 PM, Stephen Sprunk wrote: > > > >> All true, but if the space _does_ show up in the routing table, that >> creates >> the presumption that it's in use. If ARIN could contact the org and they >> justified private use, that's within current policy as well. Orgs are >> encouraged to use RFC1918 space on private networks, but they can get >> direct >> assignments for private use if they insist. That may change as we get >> closer to (or past) exhaustion, though. >> > > Is there an enumeration of the amount of space that is assigned for private > use ? > > Regards > Marshall From stephen at sprunk.org Tue May 1 14:32:57 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 1 May 2007 13:32:57 -0500 Subject: [ppml] Revised Policy Proposal Resource Reclamation References: <20070501124504.GA17437@ussenterprise.ufp.org><00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> <015001c78c17$3d3490a0$4a3816ac@atlanta.polycom.com> Message-ID: <018c01c78c1f$8bbcf5c0$4a3816ac@atlanta.polycom.com> Thus spake "Marshall Eubanks" > On May 1, 2007, at 1:18 PM, Stephen Sprunk wrote: >> All true, but if the space _does_ show up in the routing table, that >> creates the presumption that it's in use. If ARIN could >> contact the org and they justified private use, that's within >> current policy as well. Orgs are encouraged to use RFC1918 >> space on private networks, but they can get direct >> assignments for private use if they insist. That may change as >> we get closer to (or past) exhaustion, though. > > Is there an enumeration of the amount of space that is assigned for > private use ? Only RFC 1918 space is officially assigned for private use. The RIRs (and IANA, InterNIC, SRI, NSI, etc. before that) have assigned space that ended up being used privately. There used to be a "Connected" status field in WHOIS, but that's long gone. I'm not aware of ARIN ever tracking the intended use of new assignments, and many assignments have changed status over time in both directions so those records would be of dubious quality if they did exist. If you want a semi-reliable answer, you'll have to pull the various RIR databases and compare with (some view of) the global routing table. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From jordi.palet at consulintel.es Tue May 1 14:33:12 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 01 May 2007 19:33:12 +0100 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <848F083E-AE1E-43E9-9E62-C22629B1D858@delong.com> Message-ID: As we have a kind of "design-team" for the IPv6 criteria and this point was raised from there ... I was intending to include this part on that policy proposal. We may decide to split in two if it becomes too complex because it affects some other parts of the NRPM. We have not started yet to work, but I plan to draft something to discuss in the design team most probable before next week end. Regards, Jordi > De: Owen DeLong > Responder a: > Fecha: Tue, 1 May 2007 08:48:22 -0700 > Para: Michael Hertrick > CC: Public Policy Mailing List > Asunto: Re: [ppml] Definition of "Existing Known ISP" > > > On May 1, 2007, at 7:43 AM, Michael Hertrick wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I like what I've been reading, too. I like the idea of using LIR in >> lieu of ISP. >> >> Thanks, >> ~Mike. > > So do I. However, doing that requires a policy proposal. I'm actively > working on three policy proposals at this point. Two of which have been > submitted and one which is still in the preparation phase. > > My intent was to help Leslie get an idea of group consensus on > the meaning of existing policy. Anyone who wishes to make this > change is certainly welcome (I'll even say encouraged) to submit > a proposal to accomplish the above stated goal. > > I don't currently have the cycles to do it. > > Owen > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From info at arin.net Tue May 1 15:11:35 2007 From: info at arin.net (Member Services) Date: Tue, 01 May 2007 15:11:35 -0400 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: Message-ID: <463790E7.7040807@arin.net> ARIN received the following policy proposal. The author withdrew the previous proposal; it is closed. In accordance with the ARIN Internet Resource Policy Evaluation Process, this proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next regularly scheduled meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Reclamation of Number Resources Author: Owen DeLong, Stephen Sprunk Proposal Version: 1.1 Submission Date: 4/30/07 Proposal type: modify Policy term: permanent Policy statement: Resource Reclamation 1. ARIN may review the current usage of any resources allocated or assigned to an organization. The organization shall furnish whatever records are necessary to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. at any other time without cause unless a prior review has been completed in the preceding 12 months. 3. ARIN shall communicate the results of the review to the organization. 4. If the review shows that existing usage is substantially not in compliance with current allocation and/or assignment policies, the organization shall return resources as required to bring them into compliance. If an organization holds multiple ARIN delegations, they may return any number of whole delegations necessary to restore compliance. If an organization holds a single ARIN delegation, they shall return a single aggregate portion of the delegation to restore compliance. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources as required to bring the organization into compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Return or revocation of resources shall be immediate for billing purposes. 7. ARIN shall not issue any returned or revoked resources to another organization for a minimum of six months after reclamation. ARIN shall negotiate a longer term with the resource holder if ARIN believes the resource holder is working in good faith to restore compliance and has a valid need for additional time to renumber out of the affected blocks. 8. The whois database shall indicate that such blocks are scheduled for reclamation and shall display the date determined under the previous paragraph. Delete sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from section 4.2.3.1. Rationale: ARIN feels that current policy does not give them the power to audit or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to stop using any resources to be reclaimed. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From stephen at sprunk.org Tue May 1 16:30:44 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 1 May 2007 15:30:44 -0500 Subject: [ppml] Revised Policy Proposal Resource Reclamation References: <20070501124504.GA17437@ussenterprise.ufp.org> Message-ID: <01d501c78c30$ffc6b580$4a3816ac@atlanta.polycom.com> Thus spake >> of actual need). I would think on any procedural violation the >> right thing to do would be a "probation" period where the holder >> can rectify the situation, and quite frankly, if they can't comply >> with the documentation aspects I think all of their space should >> be pulled. > > You started out right but then went astray just like the original > authors. We are not police officers. We are not peacekeeping > forces in a war zone. We are not high-school principals. We > are not even the Internet's HR department. > > We are just a bunch of people who share fate through a shared > resource which happens to be limited in nature. Language like > "probation" is inappropriate for ARIN policy as is the attitudes > that lead to including things like "all of their space should be > pulled". Agreed so far. > Yes, it would be good for ARIN to have some powers to audit > usage. But this is not the way to go about it. ARIN _already_ has unlimited power to audit usage per the RSA. This proposal is an attempt to specify how that power should be used instead of leaving it up to staff. How is that a bad thing? > First of all, any ARIN actions around auditing should start with > the issue of records and reporting. I'm not suggesting that we > go the way of NANPA with regular usage and runout reports, > but that if we want ARIN to get involved in auditing usage, the > first step is to *HELP* (not force) the orgs to do their own > internal auditing and reporting. The first step is for ARIN to > develop and publish some standards for recordkeeping. Unfortunately, helping people and developing tools are not policy matters. Feel free to make suggestions to the Board; in fact, I believe that doing those things would make everyone's lives easier and, in the long term, save ARIN money. > After that, perhaps the problems will go away. Or maybe not > and we will need to go to the next step where ARIN can demand > to review the said records and audit them for accuracy. You > cannot audit records which do not exist and you cannot audit > records which are in disarray. The intent is that the same records would be used in a review that would be used in any request for an allocation or assignment today. If you don't have them, then you shouldn't have been able to get those resources in the first place unless it was a long, long time ago and you've never asked for anything new since. Except in cases where ARIN has cause to suspect fraud, they would trust that you're not lying (much), just as they do today. I avoided using the term "audit" because that implies having to prove your records are correct (e.g. to the IRS). > As for what is to be done when records are audited and found > to be defficient, pulling *ALL* address space is the wrong thing. > Such language has no place in ARIN policy. Possibly there is > a place for pulling unjustified address space, but that *MUST* > be done in a reasonable way with renumbering transition > periods, etc. The proposal at hand addresses those issues. > In fact, after it is determined that an org cannot demonstrate > technical justification for their existing address space, the > right action for ARIN to take is dependent on the state of their > recordkeeping. If bad records are the reason why they cannot > demonstrate justification, then ARIN should start by ordering > them to bring their records into order, and give them time and > assistance to do so. Part of that assistance is the above- > mentioned standards for recordkeeping. If the org has good > enough records but just lack the justification, then ARIN > should order a remediation plan. That's effectively what the proposal does, though not in so many words. The org has to produce records sufficient for ARIN to complete the review, and if they don't have them, they need to generate them. If those records then show that the resources aren't justified, the remediation plan is either return or revocation, i.e. reclamation. > This will also give the org ample time to deal with any issues > surrounding renumbering, but it also allows the org to do > things like acquire new customers and thus acquire the > technical justification that they need. They could buy another > ISP and renumber all their customers and give back the other > ISP's addresses instead of their own. The proposed grace period gives them time to renumber. If they later happen to justify the resources before they're reclaimed, they could submit an application showing that and ARIN would logically reissue those resources back to them. > ... I believe that ARIN's role here has to be in helping an org > reach compliance, not in punishing an org or pulling the rug out > from under them. ARIN cannot help an org reach compliance. ARIN could, however, help them prove they were in compliance. There's a serious difference there. > The fact is that for many years (and maybe still to this day) there > has not been any accepted description of what constitutes > technical justification for IPv4 address allocations/assignments. > In the absence of a clear description, thousands of engineers > and managers have built up networks and businesses thinking > that they were following ARIN guidelines in good faith. ARIN has policy on what justifies an allocation/assignment. It has changed slowly over time, but not so much that someone still assuming rules from five years ago is likely to be in trouble today. However, the rules _will_ change significantly in the future and reclamation will be unavoidable. I think it's best to get people (including staff!) used to the idea of reviews, what documentation they'll need, etc. now while they're still highly likely to pass. > You simply cannot turn 180 degrees and attack these people > who have been acting in good faith. That isn't the intent. > This policy proposal is a bad, bad thing and I hope that it is > withdrawn before it ever reaches the next ARIN meeting. > Wordsmithing is not the answer. A completely different take on > the issue is needed and we need to begin with the right attitudes. > Remember, ARIN's charter includes education but does not > include enforcement. The charter requires stewardship. We would be irresponsible stewards if we did not verify the need of people consuming a limited resource that others _can_ justify a need for. Helping people document their justification would be nice, and I encourage the Board to budget money for developing tools to that end, but it's not enough -- and it's not policy. > First, I believe that the majority of ISPs have addresses that they > could reuse if they only knew where they are. Helping everyone > find their internal wastage and inefficiency, will lead to smaller > requests for new addresses. See above. Even the simple but highly popular idea of a web interface, which presumably would show all the resources an org has and what they're tagged for, would be a step in the right direction. If the tools existed, we could force people to use them, but we can't use policy to create them out of thin air. ( In fact, a tool could be made to check compliance status; a review would merely consist of ARIN looking at the tool and, if the report wasn't positive, asking the org to make sure their data is up to date. ) > And the second way is that the publicity surrounding this effort > will raise awareness of IPv4 exhaustion and drive people towards > demanding IPv6 services. I doubt it; by itself, reclamation will extend the life of v4 a few months, a year at the most. However, I predict we're going to start making more significant policy changes (which _will_ get publicity) as we get closer to the wall, and we'll need some sort of reclamation mechanism for those policies to have any meaningful effect. > Remember, everything that ARIN does surrounding IPv4 > exhaustion will attract great media attention. Choose your > policy proposals wisely. Just getting the media to understand that IPv4 exhaustion will happen in the next 5-10 years and what that means will be enough of a challenge. Once they do start paying attention, it'll be too late to matter and/or they'll misreport everything anyways. Remember Y2k? I can already see headlines like "ARIN says only computers with Windows Vista will be allowed on the Internet" coming. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From bicknell at ufp.org Tue May 1 18:44:15 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 1 May 2007 18:44:15 -0400 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: <20070501124504.GA17437@ussenterprise.ufp.org> Message-ID: <20070501224415.GA43015@ussenterprise.ufp.org> In a message written on Tue, May 01, 2007 at 03:28:35PM +0100, michael.dillon at bt.com wrote: > In fact, after it is determined that an org cannot demonstrate technical > justification for their existing address space, the right action for > ARIN to take is dependent on the state of their recordkeeping. If bad > records are the reason why they cannot demonstrate justification, then > ARIN should start by ordering them to bring their records into order, > and give them time and assistance to do so. Part of that assistance is > the above-mentioned standards for recordkeeping. If the org has good > enough records but just lack the justification, then ARIN should order a > remediation plan. This will also give the org ample time to deal with > any issues surrounding renumbering, but it also allows the org to do > things like acquire new customers and thus acquire the technical > justification that they need. They could buy another ISP and renumber > all their customers and give back the other ISP's addresses instead of > their own. This is like when a court orders an accounting firm to run a > business's financial affairs rather than ordering a bankruptcy. I use > this analogy specifically because I believe that ARIN's role here has to > be in helping an org reach compliance, not in punishing an org or > pulling the rug out from under them. Perhaps you and I have a different definition of the word "probation", but to me that's exactly what you describe here. If the records are not in order, they get put on probation, during which time they make amends (update records, remediation plan, etc). Perhaps also important is that an org on probation can't get new resources. I don't think that needs to be in the policy, that's already the way it is....if you can't justify your current resources you don't get more. What I suggested and you jumped on is that if the org refused to update their records, or refused a reasonable remediation plan then and only then would the proper recourse to be to revoke all of their assignments. Why is this important? Otherwise there's no reason. If I don't believe I'll need more IP space for the life of IPv4, and ARIN comes to audit me, what's the penality for saying no? Of course, if the org has proper records and has simply shrunk over time such that now a large amount of their space is unused, then a partial reclamation is the absolutely appropriate thing to do, and ARIN should be lenient with time frames for that to happen. > The fact is that for many years (and maybe still to this day) there has > not been any accepted description of what constitutes technical > justification for IPv4 address allocations/assignments. In the absence > of a clear description, thousands of engineers and managers have built > up networks and businesses thinking that they were following ARIN > guidelines in good faith. I believe ARIN policy and operational procedures make it clear to many people on a daily basis what constitutes justification. Every single new space allocation meets that standard, so I'm not sure why anyone would think the standard is a mystery or undefined. > You simply cannot turn 180 degrees and attack these people who have been > acting in good faith. If it means that we run into the brick wall of This is not a 180 degree turn. It's perhaps a 10 degree turn. Today anyone applying for new resources may have to fully document all existing ARIN allocations in order to get new space. Anyone who may need additional space in the future should already be prepared to do everything this policy requires, or they are in big trouble. The only thing this policy does is to add a second trigger, now not only a new request but being dormant for too long will trigger the same level of review. I suspect there's a lot of low hanging fruit too. Many small ISP's are partnerships, that might get a /19. Then fail. One partner takes the /19 and starts using 10 addresses for a new ASP business, and keeps paying the fee. He never requests more, so an ARIN review is never triggered. Yet there is massive waste. -- 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 sandy at tislabs.com Tue May 1 18:46:30 2007 From: sandy at tislabs.com (Sandy Murphy) Date: Tue, 1 May 2007 18:46:30 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: Message-ID: <20070501224630.C109B3F439@pecan.tislabs.com> A long response illicited by Ed Lewis's comment: >Let's say I get someone to sign a key for me with an identity of Owen >DeLong. If ARIN accepts that someone as a trusted introducer, then >how can ARIN distinguish between templates submitted by me signed >with my Owen key and templates Owen genuinely submits? Summary: among the hardest parts of security, as the "recognized security experts" Michael Dillon likes to point to would probably tell you, are the trust model and key management. All of the following is based only on reviewing the ARIN documents I've been seen on the web site; i.e., no actual experience. Currently, the steps to getting and managing resources are: (1) Establish POC - Send in a POC template - ARIN reviews this. [1] - A response is sent. [2] Presumably the response includes the POC handle, which uniquely identifies the POC. (2) Establish an OrgID - Send in the Org template, which points to the POC handle - ARIN ensures that the requestor works for the organization [3][4][5] (3) Request/Reallocate/Return/etc resources - Send in template, which points to POC handle - ARIN looks up POC Handle to see authentication type. If authentication type is MAIL-FROM, ARIN checks the email message header From field, which must match the (or any) email address associated with the POC handle. Note that what is being authenticated in Step 3 is the POC Handle, not the identity. Spoofable? Certainly in Step (3). Step (1), maybe, depending on what ARIN does at this step. The legal entity part of the verification of Step 2 is a matter of staff process (one presumes they are doing a great job) and verification of the tie from Org to POC is hinted at in the text, but no verification of the tie from POC to Org is mentioned. Caveats/Questionable parts: [1] It is unclear is ARIN does any identity verification at this point - I've heard people say No, but hearsay is ... unreliable. [2] Oddly, the web site says "will notify the organization, via e-mail to the individual who submitted the request", although there's not necessarily an organization tied to the POC. Anyway, it's not clear if that email goes to the email address in the POC template or to the email address from which the request came. [3] ARIN "requires written proof that the individual making the request either works for the organization or has been authorized to make the request." But it doesn't say that the individual making the request must be one of the POCs listed in the template. [4] ARIN "will notify the organization, via e-mail to the individual who submitted the request," which depending on the answer to the previous question may or may not be one of the POCs listed. I'm not guessing that it is *all* of them. [5] Any verification that the Admin/Tech/Abuse POCs all agree that they work for the organization? Might be nifty to claim that some well known person had agreed to serve in a role in my new organization - say, an AC or BoT member. Or someone I dislike. When PGP is implemented: (1) Establish POC - Send in POC template - Associate a PGP key with the POC template This will be a matter of staff determined process, and presumably will involve proof of knowledge of the private key. - ARIN will check its trust in the key, hence the identity [6], by checking the signatures on the key and the length of the chain to one of the introducers they trust. Many times, there is also phone contact to read off key footprint (additional proof of identity). (2) Establish OrgID - Same as above - Note that, *IF* the Org request has to come from one of the POCs, there is an opportunity here to get the request signed by one of the POCs. Not all of them, of course, so there's still an issue of verifying the ties from POC to Org and from Org to POC. (3) Request/Reallocate/Return/etc - Send in signed template, which points to POC Handle - ARIN looks up POC Handle, sees PGP as authentication type, gets the associated key and checks the signature. Caveats/Questionable parts: [6] Why does ARIN care about the identity? I'm not positive, especially if ARIN does not currently verify identity on POC template submission. But if the Org request review involves checking that all POC names actually work for the organization, being careful about the identity makes sense.] Note that what is being authenticated in Step 3 is still the POC Handle, not the identity. Spoofable? Not easily in Step 3. Even if Ed Lewis gets Careless Trusted Introducer (oxymoron?) to sign a key saying he is Owen DeLong, and sends in a template requesting some action for a resource for which Owen is the POC, the signature won't check against Owen's POC Handle's stored key. If Owen loses his private key, though, all bets are off. But it is spoofable in Step 1. First, if ARIN has been sadly deceived in the trust they place in one of their Trusted Introducers, there can be a problem of accepting POC templates that refer to bogus identities. Note that doesn't create spoofing problems with existing POCs. Secondly, if ARIN accepts requests for rekeying (hey, ARIN, I lost the private key for my PGP key - here is another PGP key identifying me as Owen DeLong which you should store for POC Handle "Owen-Handle") without sufficient checking, then Step 3 ends up being spoofable also. So. Trust model (who your trusted introducers are) and key management (intial keying and rekeying) are places to be careful. --Sandy From michael.dillon at bt.com Tue May 1 20:29:44 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 2 May 2007 01:29:44 +0100 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: <01d501c78c30$ffc6b580$4a3816ac@atlanta.polycom.com> References: <20070501124504.GA17437@ussenterprise.ufp.org> <01d501c78c30$ffc6b580$4a3816ac@atlanta.polycom.com> Message-ID: > Unfortunately, helping people and developing tools are not policy matters. I strongly disagree on that point. I certainly don't want to see policy which goes into too much detail on such things, but I think that it is entirely appropriate for ARIN policy to specify broadly what type of educational activities ARIN should engage in, as well as what sort of tools it should develop. For instance, I supported the broad thrust of the PGP policy which directed ARIN to build tools so that communications with ARIN could be authenticated with PGP. The fact is that ARIN policy has never had much detail on what constitutes justification for an IP address block. There is a bit more detail in RFC 2050 but nowhere is there an explanation of what documentation is sufficient to show "justification" or what records must be kept. This is very different from NANPA who allocate blocks of telephone numbers and who not only have specific documentation requirements, but don't really need to audit much since orgs must submit regular reports on their actual utilisation complete with estimated runout dates. > The intent is that the same records would be used in a review that would > be > used in any request for an allocation or assignment today. If you don't > have them, then you shouldn't have been able to get those resources in the > first place unless it was a long, long time ago and you've never asked for > anything new since. People misplace old documents, especially when a role travels from one employee to another. And acquisitions happen. And systems are obsoleted and replaced. And many companies require old documents to be destroyed/deleted unless they meet certain criteria. If the ARIN contact for an org tells their management that records must be kept, and management doesn't see a business case for doing so, AND THERE ARE NO ARIN POLICIES DETAILING WHAT RECORDS MUST BE KEPT, then bitrot sets in. The fact that a database exists and has lots of records in it, doesn't mean that the data continues to be valid. Most companies go through regular cycles of data cleansing to clean out crud and correct errors but these often never get more than 80% done before something else takes priority. > Except in cases where ARIN has cause to suspect fraud, they would trust > that > you're not lying (much), just as they do today. I avoided using the term > "audit" because that implies having to prove your records are correct > (e.g. > to the IRS). Audit is a general accounting term totally unrelated to the IRS. It refers to the process of crosschecking records looking for inconsistencies that would indicate someone is falsifying data or siphoning off money etc. It is a perfectly valid term to use in a policy which asks ARIN to check a company's records to make sure that JUSTIFICATION for an address block continues to exist. > org has to produce records sufficient for ARIN to complete the review, and > if they don't have them, they need to generate them. This is what I object to. I strongly object to ARIN contacting me and demanding that I show justification, not just for 6 months supply of addresses, but 15 years or so. I would object less to a policy which defines the records that I must keep on hand, and mentions, in one clause, that ARIN can request me to submit these defined records at any time. If I know in advance, what records I need to submit, then I can start sorting out data cleanliness issues today, long before anyone asks for the records. If ARIN policy defines the records that I must keep, then I can more easily make an internal business case for any system and process changes necessary to do this right. It's not that I can't reverse engineer the network and get this info, its just that said reverse engineering is time consuming and its harder to spread the workload. Even in a small organization, where everything is in a folder full of spreadsheets, they run into bitrot and data cleanliness issues. > The proposed grace period gives them time to renumber. The grace period is not stated as a time for the org to renumber but as a waiting period for ARIN before reissuing the addresses. Why isn't it 12 months like in 4.6 Amnesty requests. Why isn't it tied to the last allocation period, i.e. did they ask for a 3 or 6 month supply? There is a similar situation with the LIRs customers. When a customer moves to another ISP, they are supposed to return and renumber. Not only does 4.2.3.3 not specify 6 months, it doesn't mention any specific time period. Why doesn't this proposal fix that? Also, the customer does not have to return the block until after the renumbering period, but the proposal asks ARIN to pull back the block from the LIR first, before the renumbering period. These kinds of flaws show that very little thought went into this proposal an almost no effort was made to make it fit into the set of existing policies. These kinds of proposals don't make any sense and I can't figure out what the point is of submitting them, other than to waste our time. This is a proposal to make a MAJOR change to ARIN practice. Such a proposal should not even be submitted before it is vetted in detail by several people. By "in detail" I mean that they suggest a lot of changes and adjustments that show they did more than spend 5 minutes scanning the proposal. And the proposal needs to be checked against the entire existing policy set to find out where there are mismatches, gaps, etc. > > ... I believe that ARIN's role here has to be in helping an org > > reach compliance, not in punishing an org or pulling the rug out > > from under them. > > ARIN cannot help an org reach compliance. ARIN could, however, help them > prove they were in compliance. There's a serious difference there. If ARIN would use the education hat to deal with this issue, then they could indeed help an org reach compliance. I'm not asking them to send out free consultants to spend a week in your office. > ARIN has policy on what justifies an allocation/assignment. It has > changed > slowly over time, but not so much that someone still assuming rules from > five years ago is likely to be in trouble today. Where is it defined so clearly that ARIN can be confident they will not be sued if they claim that an org no longer "justifies" their allocation? The policy does not have to be written in a way that attracts lawsuits. > I > think it's best to get people (including staff!) used to the idea of > reviews, what documentation they'll need, etc. now while they're still > highly likely to pass. So you believe that it is OK to provide documentation and education to staff but not OK to do the same for ARIN members? Something is wrong here. > The charter requires stewardship. We would be irresponsible stewards if > we > did not verify the need of people consuming a limited resource that others > _can_ justify a need for. IP addresses are virtually unlimited. IPv4 may be running low, but there is a vast supply of IPv6 addresses now available. Here again, ARIN is failing its charter because it is not taking its education role seriously. Almost all the people involved, from staff, to BoT to AC to member contacts, have been in this business too long and are being blindsided by changes to the environment in which we all function. What we have here is a failure of the imagination. Read the report on 9/11 and the Challenger disaster to see what happens when people get complacent and stuck in their ways. Tradition does not work well in the modern world. > See above. Even the simple but highly popular idea of a web interface, > which presumably would show all the resources an org has and what they're > tagged for, would be a step in the right direction. If the tools existed, > we could force people to use them, but we can't use policy to create them > out of thin air. I would build the tool myself and give it away if I only knew what darned data it NEEDS to have in it. And if that data spec was truly based on need-to-know, not corporate espionage requirements or someone's fantasy of big-brother watching for the evil spammers. Of course, we are really talking about publishing data to a few ARIN employees who work behind a chinese wall, not to the whole world, so I may be somewhat more lenient, but I still believe that the data spec must be based on what ARIN needs to know in order to justify an assignment from my allocation. > ( In fact, a tool could be made to check compliance status; a review would > merely consist of ARIN looking at the tool and, if the report wasn't > positive, asking the org to make sure their data is up to date. ) This is fantasy. The reason audit processes exist is because of a whole range of human issues which lead to bitrot. ARIN may trust me but do they trust my data sources within the organization and all the many people who monkey with that data? --Michael Dillon From michael.dillon at bt.com Tue May 1 20:33:19 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 2 May 2007 01:33:19 +0100 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: <00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> References: <20070501124504.GA17437@ussenterprise.ufp.org> <00cb01c78c05$69367450$4a3816ac@atlanta.polycom.com> Message-ID: > However, my impressions are that the staff finds > that idea as distasteful as we do and that they aren't interested in > revocations unless a given situation is so obviously b0rked that their > conscience leaves them no choice. In that case this whole proposal is an utter waste of time. You have a minor problem so you want to create a sledgehammer that will rarely be used. What is the point? The money that ARIN would spend on implementing such a policy (staff training, systems) would be better spent on educational material. --Michael Dillon From michael.dillon at bt.com Tue May 1 20:45:55 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 2 May 2007 01:45:55 +0100 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <20070501224630.C109B3F439@pecan.tislabs.com> References: <20070501224630.C109B3F439@pecan.tislabs.com> Message-ID: > Summary: among the hardest parts of security, as the "recognized > security experts" Michael Dillon likes to point to recognize security experts, anyway - beanies? bowties? I believe I mentioned that. People with GIAC certification, people who regularly speak at security conferences, people who regularly publish papers on security in peer-reviewed journals. Doesn't mean that there aren't others who know a lot about security, just that it's best to avoid arguing who is a real expert and defer to the security community on that point. I don't qualify under any of those criteria so, even though I have a fairly good grasp of security matters, I wouldn't want ARIN to take any of my advice without checking it with a "security expert". Same goes for all the other armchair experts out there. --Michael Dillon From andy at nosignal.org Wed May 2 11:38:36 2007 From: andy at nosignal.org (Andy Davidson) Date: Wed, 2 May 2007 16:38:36 +0100 Subject: [ppml] 240/4 In-Reply-To: References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> Message-ID: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> On 25 Apr 2007, at 23:54, David Conrad wrote: > The cost of redesignating class E space is the cost of writing an > RFC, IANA editing a file, and IANA publishing that file on IANA's > web site. While the first bit may cost a bit of stomach lining and > sanity, I don't think anyone can call the cost anything but very low. Agreed. You volunteering ? :-) > The cost of utilizing class E space will likely be significantly > higher. However, if you judge the cost of utilization high, don't > use it. That is, "Doctor, it hurts when I do this..." If the C in CIDR really does mean classless, then the concept of Class-E ought to start to smell old in 2007. If Vendor fixes hit routing software in 2007, so that class E .. or 240/4 .. was nothing special, then we might just have bought ourselves a little more time, come July 2011 (Geoff's best guess today when IANA's v4 'stock' runs out). -a -- Andy Davidson - ( http://www.andyd.net/ ) From sandy at tislabs.com Wed May 2 12:12:43 2007 From: sandy at tislabs.com (Sandy Murphy) Date: Wed, 2 May 2007 12:12:43 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <20070501224630.C109B3F439@pecan.tislabs.com> Message-ID: <20070502161243.5C6CF3F460@pecan.tislabs.com> Rob Seastrom points out that when I said: >A long response illicited by Ed Lewis's comment: I actually meant "elicited", not "illicited". The combination of "illicit" with a security related comment (and Ed Lewis to boot!) was just way too humorous to pass up posting. --Sandy From owen at delong.com Wed May 2 15:52:13 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2007 12:52:13 -0700 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <2316.1177975657@sa.vix.com> References: <4635E419.1030801@neovera.com> <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> <2316.1177975657@sa.vix.com> Message-ID: <550F1737-5EC7-477E-A127-587135459C3D@delong.com> > > if an asp or web hosting company allocates a /32 to an organization > other > than itself, for example a customer with an SSL service (where it's > impossible > due to the protocol design to put more than one customer on an IP > address) > then they are in my opinion, by ARIN's current definition, an ISP. > they also > need portable multihomable address space since it is otherwise > impossible, due > to the routing system design, to compete on reachability and price > level > against larger/older providers. ARIN doesn't do protocol design > like SSL nor > routing system design like BGP, but we have to recognize the > effects on the > industry of design choices made in those protocols and systems. > In general, if you are assigning /32s to customer utilization, but, not to independently routed segments (e.g. you have a bunch of customers on the same server each assigned a /32), then, no, you don't meet ARIN's definition of an ISP. If you are, for some bizarre reason, routing /32s as separate segments, then, I suppose, technically, you are reassigning networks and meet the ARIN test for ISP-ness if you want to. Portable Multihomable addresses for ASPs and the like are usually handled under the Multihomed End User policies. At least such was the case with Netli and some other ASPs I have worked with. > note that these are my opinions alone, and may not reflect those of > the board > of trustees, nor my daytime employer. Understood. As are mine above. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From dsd at servervault.com Wed May 2 16:19:54 2007 From: dsd at servervault.com (Divins, David) Date: Wed, 2 May 2007 16:19:54 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <2316.1177975657@sa.vix.com> References: <4635E419.1030801@neovera.com><0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> <2316.1177975657@sa.vix.com> Message-ID: I am a Web Hosting/DataCenter Company. I am considered an ISP by ARIN Policies. -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 Paul Vixie Sent: Monday, April 30, 2007 7:28 PM To: Public Policy Mailing List Subject: Re: [ppml] Definition of "Existing Known ISP" > > I think that today's definition of ISP not not limited to user > > access, transit, and backbone services as it once was. Companies > > providing web hosting and co-location services should be considered > > ISPs. For that matter, there are also companies that call > > themselves ASPs, Application Service Providers, that have the same > > Internet number needs as ISPs. ... > I agree with much of what you're saying here and in the rest of your > email, but I don't completely agree with where you end up. All ASPs, > web hosting companies, and colo providers are not ISPs in the sense > that the term is used in the NRPM. ... > > The defining characteristic of an "ISP" as referenced in the NRPM is > that the organization reassigns address space to organizations other than itself. > ... and I think most colo providers do fit this model and should be > classed as ISPs. if an asp or web hosting company allocates a /32 to an organization other than itself, for example a customer with an SSL service (where it's impossible due to the protocol design to put more than one customer on an IP address) then they are in my opinion, by ARIN's current definition, an ISP. they also need portable multihomable address space since it is otherwise impossible, due to the routing system design, to compete on reachability and price level against larger/older providers. ARIN doesn't do protocol design like SSL nor routing system design like BGP, but we have to recognize the effects on the industry of design choices made in those protocols and systems. note that these are my opinions alone, and may not reflect those of the board of trustees, nor my daytime employer. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From alh-ietf at tndh.net Wed May 2 16:43:16 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 2 May 2007 13:43:16 -0700 Subject: [ppml] 240/4 In-Reply-To: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> Message-ID: <00ff01c78cfa$84cb5820$8e620860$@net> Andy Davidson wrote: > ... > If Vendor fixes hit routing software in 2007, so that class E .. or > 240/4 .. was nothing special, then we might just have bought > ourselves a little more time, come July 2011 (Geoff's best guess > today when IANA's v4 'stock' runs out). The misguided notion that this is simply a routing problem will result in a lot of burned resources with absolutely no gain. Even if you magically had the ability to route that space today, what customer end systems would you be able to stick there? If you write the draft now and ram it through as an RFC in less than a year, you would be extremely lucky to find 1% of the globally deployed end systems actually able to exist in a network that has been assigned part of that block before 2012. It is worth writing it up for Greenfield deployments of closed systems that will not need to include any of the Win9x systems that will continue to be in use. Tony From drc at virtualized.org Wed May 2 16:45:23 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 2 May 2007 13:45:23 -0700 Subject: [ppml] 240/4 In-Reply-To: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> Message-ID: <45A75C3E-1813-4261-8C78-64CAE0E888C4@virtualized.org> On May 2, 2007, at 8:38 AM, Andy Davidson wrote: >> The cost of redesignating class E space is the cost of writing an >> RFC, IANA editing a file, and IANA publishing that file on IANA's >> web site. While the first bit may cost a bit of stomach lining >> and sanity, I don't think anyone can call the cost anything but >> very low. > > Agreed. You volunteering ? :-) I'd be happy to write a draft redesignating the class E space if somebody can tell me what the consensus is on what it should be redesignated to, e.g., "normal" unicast? RFC-1918 extension? Half- and-half? Something else? Rgds, -drc From owen at delong.com Wed May 2 16:52:03 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2007 13:52:03 -0700 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: <4635E419.1030801@neovera.com><0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> <2316.1177975657@sa.vix.com> Message-ID: <51D65182-BEE8-40D6-9307-235251E41CB8@delong.com> On May 2, 2007, at 1:19 PM, Divins, David wrote: > I am a Web Hosting/DataCenter Company. I am considered an ISP by ARIN > Policies. > In all likelihood, a substantial portion of your assignments do not meet the test I specified below for a non-ISP version of an ASP or Hosting company. Indeed, most hosting companies that are also DataCenter companies would not. Most Web Hosting companies that are hosting a bunch of domains on shared server infrastructure, however, would. Most ASPs fall into this latter category, but, not all. It's all about how you reassign the addresses and topology, not business category. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From Alain_Durand at cable.comcast.com Wed May 2 16:55:35 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Wed, 2 May 2007 16:55:35 -0400 Subject: [ppml] 240/4 Message-ID: To the list of win 9x systems, you may add a lot others, think embeded systems that have old stacks... Testing those systems for compatibility with 240/4 will also take quite some time. In practice, 240/4 is not useable anywhere in the near future. Unfortunate but true. Yes, this could be fixed but will take a large amount of resources from all equipment/software vendors and everybody using them to certify them. IMHO, I'd rather like to see vendors spending their limited resources making their product fully workable with IPv6. - Alain. ----- Original Message ----- From: ppml-bounces at arin.net To: 'Andy Davidson' ; 'David Conrad' Cc: 'Public Policy Mailing List' Sent: Wed May 02 16:43:16 2007 Subject: Re: [ppml] 240/4 Andy Davidson wrote: > ... > If Vendor fixes hit routing software in 2007, so that class E .. or > 240/4 .. was nothing special, then we might just have bought > ourselves a little more time, come July 2011 (Geoff's best guess > today when IANA's v4 'stock' runs out). The misguided notion that this is simply a routing problem will result in a lot of burned resources with absolutely no gain. Even if you magically had the ability to route that space today, what customer end systems would you be able to stick there? If you write the draft now and ram it through as an RFC in less than a year, you would be extremely lucky to find 1% of the globally deployed end systems actually able to exist in a network that has been assigned part of that block before 2012. It is worth writing it up for Greenfield deployments of closed systems that will not need to include any of the Win9x systems that will continue to be in use. Tony _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From drc at virtualized.org Wed May 2 16:58:32 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 2 May 2007 13:58:32 -0700 Subject: [ppml] 240/4 In-Reply-To: <00ff01c78cfa$84cb5820$8e620860$@net> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> Message-ID: On May 2, 2007, at 1:43 PM, Tony Hain wrote: > If you write the draft now and ram it through as an RFC in less > than a year, > you would be extremely lucky to find 1% of the globally deployed > end systems > actually able to exist in a network that has been assigned part of > that > block before 2012. > > It is worth writing it up for Greenfield deployments of closed > systems that > will not need to include any of the Win9x systems that will > continue to be > in use. This would appear to argue for RFC 1918 extension. Rgds, -drc From alh-ietf at tndh.net Wed May 2 17:05:51 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 2 May 2007 14:05:51 -0700 Subject: [ppml] 240/4 In-Reply-To: References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> Message-ID: <010e01c78cfd$ab6e8530$024b8f90$@net> David Conrad wrote: > On May 2, 2007, at 1:43 PM, Tony Hain wrote: > > If you write the draft now and ram it through as an RFC in less > > than a year, > > you would be extremely lucky to find 1% of the globally deployed > > end systems > > actually able to exist in a network that has been assigned part of > > that > > block before 2012. > > > > It is worth writing it up for Greenfield deployments of closed > > systems that > > will not need to include any of the Win9x systems that will > > continue to be > > in use. > > This would appear to argue for RFC 1918 extension. Kind of, but it is really a separate thing. If you make it in any way related to 1918 then people will end up assigning it to networks that include pre-definition end systems, even though this is known to fail. What it has to be is its own version of a private-use that has limited applicability to new Greenfield deployments that have absolutely no expectation of including anything that exists today. Tony From drc at virtualized.org Wed May 2 17:06:46 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 2 May 2007 14:06:46 -0700 Subject: [ppml] 240/4 In-Reply-To: References: Message-ID: <7C0BFC71-C738-4D7A-8A67-19163747AA0D@virtualized.org> Alain, On May 2, 2007, at 1:55 PM, Durand, Alain wrote: > Yes, this could be fixed but will take a large amount of resources > from all equipment/software vendors and everybody using them to > certify them. > > IMHO, I'd rather like to see vendors spending their limited > resources making their product fully workable with IPv6. While I agree that making products fully workable with IPv6 would be better, I suspect it would be a bit easier to remove an "if" statement (yes, I'm making a large assumption) than implementing a completely new networking stack. Rgds, -drc From Alain_Durand at cable.comcast.com Wed May 2 17:08:37 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Wed, 2 May 2007 17:08:37 -0400 Subject: [ppml] 240/4 Message-ID: > This would appear to argue for RFC > 1918 extension. > > Rgds, > -drc I disagree... Any system today is expected to be able to use RFC1918. This is not the case for 240/4. - Alain. From drc at virtualized.org Wed May 2 17:14:13 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 2 May 2007 14:14:13 -0700 Subject: [ppml] 240/4 In-Reply-To: References: Message-ID: <2CE73BAC-5E20-4972-A836-D5C938CB8623@virtualized.org> On May 2, 2007, at 2:08 PM, Durand, Alain wrote: > I disagree... Any system today is expected to be able to use > RFC1918. This is not the case for 240/4. True. I meant RFC1918 in the sense that it would never be globally routed. As Tony points out, this would be private addressing for a limited set of devices (those that didn't treat class E specially). Rgds, -drc From Alain_Durand at cable.comcast.com Wed May 2 17:15:29 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Wed, 2 May 2007 17:15:29 -0400 Subject: [ppml] 240/4 Message-ID: David, I would agree with you if there were no need to certify products, make sure all vendors (even those who do not exist any more) provide a fix, differentiate the old vs new code to be deployed, and patch all existing system... In a network like ours, you are talking about a multi year effort. Yes, from a coding perspective, this is much less than implementing a new stack from scratch. However, from a deployment perspective, it is still less effort than deploying IPv6, but not significantly less. And all this to delay exhaustion by a year 1/2 at best... Not worth it IMHO. - Alain. ----- Original Message ----- From: David Conrad To: Durand, Alain Cc: Public Policy Mailing List Sent: Wed May 02 17:06:46 2007 Subject: Re: [ppml] 240/4 Alain, On May 2, 2007, at 1:55 PM, Durand, Alain wrote: > Yes, this could be fixed but will take a large amount of resources > from all equipment/software vendors and everybody using them to > certify them. > > IMHO, I'd rather like to see vendors spending their limited > resources making their product fully workable with IPv6. While I agree that making products fully workable with IPv6 would be better, I suspect it would be a bit easier to remove an "if" statement (yes, I'm making a large assumption) than implementing a completely new networking stack. Rgds, -drc From bmanning at karoshi.com Wed May 2 18:12:18 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Wed, 2 May 2007 22:12:18 +0000 Subject: [ppml] 240/4 In-Reply-To: References: <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> Message-ID: <20070502221218.GA32543@vacation.karoshi.com.> On Wed, May 02, 2007 at 01:58:32PM -0700, David Conrad wrote: > On May 2, 2007, at 1:43 PM, Tony Hain wrote: > > If you write the draft now and ram it through as an RFC in less > > than a year, > > you would be extremely lucky to find 1% of the globally deployed > > end systems > > actually able to exist in a network that has been assigned part of > > that > > block before 2012. > > > > It is worth writing it up for Greenfield deployments of closed > > systems that > > will not need to include any of the Win9x systems that will > > continue to be > > in use. > > This would appear to argue for RFC 1918 extension. > > Rgds, > -drc on the presumption that we (the IP using community) really have no intention of abandoning IPv4 anytime real soon, I think a method to place previously unusable space into the useable pool is a good thing, even it if takes years for some folks to recast their ASICs. its unrealistic to expect retrofit of all existant systems to support such a change... the cost/benefit is not there. but for new systems, sure. --bill From bicknell at ufp.org Wed May 2 20:26:32 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 2 May 2007 20:26:32 -0400 Subject: [ppml] 240/4 In-Reply-To: <45A75C3E-1813-4261-8C78-64CAE0E888C4@virtualized.org> <00ff01c78cfa$84cb5820$8e620860$@net> References: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <45A75C3E-1813-4261-8C78-64CAE0E888C4@virtualized.org> <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> Message-ID: <20070503002632.GA23356@ussenterprise.ufp.org> In a message written on Wed, May 02, 2007 at 01:43:16PM -0700, Tony Hain wrote: > The misguided notion that this is simply a routing problem will result in a > lot of burned resources with absolutely no gain. Even if you magically had > the ability to route that space today, what customer end systems would you > be able to stick there? There are multiple proposals on the table for the space. One of the proposals was by several CableCo's as additional RFC 1918 space to use to control their set top boxes and cable modems. For those deployments, having their vendors update software for the set top boxes and cable modems FULLY fixes the "problem" and makes the space usable. There are other fully homogenous environments that might be able to quickly use the space as well. In a message written on Wed, May 02, 2007 at 01:45:23PM -0700, David Conrad wrote: > I'd be happy to write a draft redesignating the class E space if > somebody can tell me what the consensus is on what it should be > redesignated to, e.g., "normal" unicast? RFC-1918 extension? Half- > and-half? Something else? It's a two part problem: #1 - Write an RFC that software should be updated to treat Class E space as normal unicast. After all, even 1918 space is just normal unicast from the perspective of virtually every device out there. #2 - Have the community decide if we want to give this out as additional 1918 space, full IP unicast space, or some "half and half" arrangement. We can use the time the vendors are fixing their code to have that debate. Since you volunteered, please write #1 ASAP. :) It will spur people to have the conversation in #2 much quicker. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Wed May 2 22:01:06 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 2 May 2007 22:01:06 -0400 Subject: [ppml] 240/4 In-Reply-To: <20070502221218.GA32543@vacation.karoshi.com.> References: <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <20070502221218.GA32543@vacation.karoshi.com.> Message-ID: At 22:12 +0000 5/2/07, bmanning at karoshi.com wrote: > on the presumption that we (the IP using community) really have >no intention of abandoning IPv4 anytime real soon When the last new IPv4 address has been given out there will still be IPv4 packets routed, IPv4 registrations to manage, and reclaimed IPv4 to be doled out. Our world doesn't completely end with the depletion of the IPv4 pools. So trying to squeeze out a few more addresses may well be worth the effort even if the IETF document cycle takes longer than the Huston/Hain predictions give us. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From michael.dillon at bt.com Thu May 3 04:38:15 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 May 2007 09:38:15 +0100 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <550F1737-5EC7-477E-A127-587135459C3D@delong.com> References: <4635E419.1030801@neovera.com><0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca><2316.1177975657@sa.vix.com> <550F1737-5EC7-477E-A127-587135459C3D@delong.com> Message-ID: > In general, if you are assigning /32s to customer utilization, but, not > to independently routed segments (e.g. you have a bunch of customers > on the same server each assigned a /32), then, no, you don't meet > ARIN's definition of an ISP. This is news to me. Since when does ARIN tell ISPs what their business model must be? I thought that ARIN's policies required an org to give "technical justification" for IP address assignments and that SSL webhosting counts as a technical justification. Where does the policy prohibit assigning addresses to customers on the same server? --Michael Dillon From michael.dillon at bt.com Thu May 3 04:53:45 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 May 2007 09:53:45 +0100 Subject: [ppml] 240/4 In-Reply-To: <45A75C3E-1813-4261-8C78-64CAE0E888C4@virtualized.org> References: <462CAEF0.1040804@arin.net><026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net><85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <45A75C3E-1813-4261-8C78-64CAE0E888C4@virtualized.org> Message-ID: > I'd be happy to write a draft redesignating the class E space if > somebody can tell me what the consensus is on what it should be > redesignated to, e.g., "normal" unicast? RFC-1918 extension? Half- > and-half? Something else? I suggest that it be redesignated entirely to normal unicast. But you should include a warning that use of these addresses MAY require patching software in end-systems and routers, therefore the RIRs should only allocate/assign these addresses with that warning. The basic approach is to make the addresses available for those who wish to use them. It is too early to provide any advice on the limitations of this address space since it may be a simple software patch to make Class E addresses work normally. The RFC should warn about possible issues and recommend that people test these addresses before applying for an allocation/assignment. The value of this RFC is that it will stimulate patching, raise awareness of the 3 to 5 year horizon for IPv4 exhaustion, and provide a small supply of addresses in the bank for one last gasp of allocations, if and when people get caught short when IPv4 non-class-E runs out. Proper stewardship of IP addresses requires that we do not FORCE people to transition to IPv6 even if this seems to provide a better cost-benefit ratio. So we need this RFC to show that we are doing all that we can to extend the life of IPv4 as long as there is demand for these addresses. One thing that should NOT be in the RFC is an RFC1918 extension. In order to be useful, and extended RFC 1918 space needs to be completely free of any limitations, even using legacy equipment like SCO Xenix servers and Windows 3.1 workstations. RFC 1918 space is widely used inside the corporate world where technology refresh is spotty at best. Of course, an RFC 1918 extension would help delay IPv4 exhaustion but it is better to explore doing that with one of the low-numbered /8 blocks, perhaps the military ones. --Michael Dillon From michael.dillon at bt.com Thu May 3 04:57:59 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 May 2007 09:57:59 +0100 Subject: [ppml] 240/4 In-Reply-To: References: Message-ID: > To the list of win 9x systems, you may add a lot others, think embeded > systems that have old stacks... Testing those systems for compatibility > with 240/4 will also take quite some time. This is a policy list not a technology list. We really can't dig into the technical issues of testing what is compatible and what is not. All we can do is make policies that create possibilities and the 240/4 RFC is the same sort of thing. When you are creating possibilities, it is irrelevant that the possibilities are not easy to realize or that not everyone can make use of them. We need an RFC to release the 240/4 space and give people permission to test it and use it if they find value in it. --Michael Dillon From michael.dillon at bt.com Thu May 3 05:07:50 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 May 2007 10:07:50 +0100 Subject: [ppml] 240/4 In-Reply-To: References: Message-ID: > In a network like ours, you are talking about a multi year effort. In a network like yours you simply filter any 240/4 announcements and block any 240/4 traffic. If the RFC tells people that there MAY be problems routing 240/4 addresses on the open Internet, and that there MAY be technical problems with software or embedded hardware, then that is sufficient. Any RFC that wants to go beyond that and define specific limitations for 240/4, such as Greenfield deployments, needs to justify those limitations and that is hard right now. We simply don't know what will work and what won't. We also don't know what is easy to fix and what is hard. Better to just warn people and instruct the RIRs to pass on the warning and not misrepresent 240/4 space as problem free. Let the end users decide how they will use it, and if some future ISPs decide there are no router issues and let it run on the open Internet, then that is fine. The RFC writer should not limit these possibilities. > Yes, from a coding perspective, this is much less than implementing a new > stack from scratch. However, from a deployment perspective, it is still > less effort than deploying IPv6, but not significantly less. And all this > to delay exhaustion by a year 1/2 at best... Not worth it IMHO. We don't know the level of effort and we don't know the cost/benefit ratio because these vary too much from organization to organization. Our job is not to be big brother and engineer the runout date, but to act as stewards and do all that a reasonable person can do to stave off exhaustion. Releasing 240/4 for general use is something a reasonable person would do. Warning people that there MAY be problems is also something a reasonable person would do. But a reasonable person would not make an executive decision for everyone in the world that 240/4 is more trouble than it is worth. --Michael Dillon From owen at delong.com Thu May 3 05:20:38 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 3 May 2007 02:20:38 -0700 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: <4635E419.1030801@neovera.com><0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca><2316.1177975657@sa.vix.com> <550F1737-5EC7-477E-A127-587135459C3D@delong.com> Message-ID: On May 3, 2007, at 1:38 AM, wrote: >> In general, if you are assigning /32s to customer utilization, but, > not >> to independently routed segments (e.g. you have a bunch of customers >> on the same server each assigned a /32), then, no, you don't meet >> ARIN's definition of an ISP. > > This is news to me. > > Since when does ARIN tell ISPs what their business model must be? I > thought that ARIN's policies required an org to give "technical > justification" for IP address assignments and that SSL webhosting > counts > as a technical justification. Where does the policy prohibit assigning > addresses to customers on the same server? Michael, It's got nothing to do with business models. It has to do with network topology. From an ARIN perspective, reassignments apply to networks, not to host addresses. If you're reassigning network segments to other entities, then, you're in the ISP definition. If you're not, then, you're probably in the end-user definition. This has nothing to do with what is or isn't legitimate address usage. It has to do with a definition of which section of the policy you fall under. The SSL webhosting counts as technical justification for end user networks where host counts and technical justification for efficient utilization within each given network are what matters. In the ISP section, what matters is the portion of network space you have assigned/reassigned and that all reassignments and assignments meet the end-user guidelines for efficient utilization. In short, ISPs are responsible for conforming to two sets of guidelines and making sure that their customers conform to one of those two sets. End users only have to conform to the one set. This is an absurd semantic interpretation of my statement and I don't understand what you think is gained for anyone by muddying the waters with it. I have already agreed that the usage of the term ISP in the policy to represent this concept is a flawed use of the term. However, absent a policy proposal to correct that wording (which I believe will probably come up shortly from another source), this thread was started as an attempt to clarify the meaning of the term FOR PURPOSES OF THE EXISTING ARIN POLICY. It's pretty clear from the context and historical application of ARIN policy that: 1. IPv4 resources issued by ARIN fall into two categories. A. Organizations who issue networks or blocks of networks to other organizations (reassignments and/or reallocations). B. Organizations who directly consume network addresses on machines owned/operated by the organization, even if those addresses are unique to particular customers of the organization. 2. The primary actual implications of the distinction between these policies fall into two categories. A. Membership -- Organizations in category 1A receive ARIN membership as part of their resource subscription fees. Organizations in category 1B do not. They can purchase ARIN membership as a separate fee. B. Fees -- Organizations in category 1A pay generally higher fees based on the total amount of resources held by the organization. They do not pay initial allocation fees, but, they do pay any applicable increase in their renewal fees upon issuance of any resource which moves them into a different fee category. Organizations in category 1B pay a flat fee of $100/year for maintenance of all of their resources, but, each request for additional resources results in an initial assignment fee for said resource(s). 3. This distinction is more about how the addresses are treated topologically than it is about business models, the actual definition of an ISP in the real world, the phase of the moon or the price of tea in China. Now, the question at hand refers to the section of ARIN policy regarding initial allocations of IPv6 address space. I believe that the clear intent of the IPv6 policy as written was to make it a no-brainer for ARIN to issue /32 allocations to any organization known to ARIN as an IPv4 reassigner/reallocator. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From bmanning at karoshi.com Thu May 3 05:19:26 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Thu, 3 May 2007 09:19:26 +0000 Subject: [ppml] 240/4 In-Reply-To: References: Message-ID: <20070503091926.GA4970@vacation.karoshi.com.> may i suggest an experiment, much along the lines of the old CIDR test with net 39. for a defined period of perhaps a year, allow folks to use addresses in net 240/4 ... collect reports of what actually works and what does not.... Once emperical evidence is in hand, it will be much easier to justify a status change for this range. --bill From BillD at cait.wustl.edu Thu May 3 05:23:17 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Thu, 3 May 2007 04:23:17 -0500 Subject: [ppml] 240/4 References: <20070503091926.GA4970@vacation.karoshi.com.> Message-ID: Gosh I like pragmatism.... bd -----Original Message----- From: ppml-bounces at arin.net on behalf of bmanning at karoshi.com Sent: Thu 5/3/2007 4:19 AM To: michael.dillon at bt.com Cc: drc at icann.org; ppml at arin.net Subject: Re: [ppml] 240/4 may i suggest an experiment, much along the lines of the old CIDR test with net 39. for a defined period of perhaps a year, allow folks to use addresses in net 240/4 ... collect reports of what actually works and what does not.... Once emperical evidence is in hand, it will be much easier to justify a status change for this range. --bill _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at nosignal.org Thu May 3 07:06:31 2007 From: andy at nosignal.org (Andy Davidson) Date: Thu, 3 May 2007 12:06:31 +0100 Subject: [ppml] 240/4 In-Reply-To: <00ff01c78cfa$84cb5820$8e620860$@net> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> Message-ID: <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> On 2 May 2007, at 21:43, Tony Hain wrote: > It is worth writing it up for Greenfield deployments of closed > systems that will not need to include any of the Win9x systems that > will continue to be in use. Yes they are, but we are talking about being ready for 2012, when the Win9x base of systems will be old enough to marry without permission (in the UK). "Modern" (by today's standard) OSes can be patched. From dlw+arin at tellme.com Thu May 3 12:07:28 2007 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 3 May 2007 09:07:28 -0700 Subject: [ppml] 240/4 In-Reply-To: <20070502221218.GA32543@vacation.karoshi.com.> References: <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <20070502221218.GA32543@vacation.karoshi.com.> Message-ID: <20070503160728.GE22657@shell01.corp.tellme.com> On Wed, May 02, 2007 at 10:12:18PM +0000, bmanning at karoshi.com wrote: > on the presumption that we (the IP using community) really have > no intention of abandoning IPv4 anytime real soon, I think a method to > place previously unusable space into the useable pool is a good thing, > even it if takes years for some folks to recast their ASICs. > its unrealistic to expect retrofit of all existant systems to > support such a change... the cost/benefit is not there. but for new > systems, sure. I agree. It's not like IPv4 will suddenly cease to be useful when we exhaust the existing pool of addresses. Even if it takes until 2020 to make 240/4 useful, it would still be useful. -David From kloch at kl.net Thu May 3 12:38:00 2007 From: kloch at kl.net (Kevin Loch) Date: Thu, 03 May 2007 12:38:00 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: <4635E419.1030801@neovera.com><0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca><2316.1177975657@sa.vix.com> <550F1737-5EC7-477E-A127-587135459C3D@delong.com> Message-ID: <463A0FE8.7000106@kl.net> Owen DeLong wrote: > Michael, > > It's got nothing to do with business models. It has to do with network > topology. > From an ARIN perspective, reassignments apply to networks, not to host > addresses. Well you could consider a host address a network with prefix length of /32. In fact ARIN will ask you for a list of /32 assignments if you have a significant number of them, even though you are not required to SWIP or put them in rwhois. I think there are two key things that differentiate between ISP and end users: 1 ISPs assign addresses delegated to them to other organizations (even if only in /32's), end users do not. 2. ISP's provide IP transit services for customers to 3rd party networks, end users do not. This includes even trivial webhosts and ASP's and anyone who fits in the middle of: [Customer -> You -> other networks] If you "provide Internet Service" it would seem that you should be called an "ISP". LIR seems to imply only #1. ISP certainly implies #2 and by arin policy also #1. I prefer the term ISP, it seems to be more clear and direct language (I'm having George Carlin flashbacks...) There is a public benefit to have anyone who is actually providing Internet services to be considered an ISP under ARIN policy. This does not mean that they would automatically meed the minimum requirements for a delegation from ARIN but if they do they should not be considered an end site. - Kevin From alh-ietf at tndh.net Thu May 3 13:08:31 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 3 May 2007 10:08:31 -0700 Subject: [ppml] 240/4 In-Reply-To: <20070503002632.GA23356@ussenterprise.ufp.org> References: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <45A75C3E-1813-4261-8C78-64CAE0E888C4@virtualized.org> <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <20070503002632.GA23356@ussenterprise.ufp.org> Message-ID: <010001c78da5$ad240e10$076c2a30$@net> Leo Bicknell wrote: > In a message written on Wed, May 02, 2007 at 01:43:16PM -0700, Tony > Hain wrote: > > The misguided notion that this is simply a routing problem will > result > > in a lot of burned resources with absolutely no gain. Even if you > > magically had the ability to route that space today, what customer > end > > systems would you be able to stick there? > > There are multiple proposals on the table for the space. One of the > proposals was by several CableCo's as additional RFC 1918 space to use > to control their set top boxes and cable modems. For those > deployments, having their vendors update software for the set top boxes > and cable modems FULLY fixes the "problem" and makes the space usable. I am aware of that, and was thinking along those lines when I suggested Greenfield deployments, but even then it is not as clean as 'just fix the set tops'. There is a pile of back-end support software that nobody knows what it will do, and that software runs on general purpose OS systems. The set top system is not completely closed, but there is at least a hope. Tony > There are other fully homogenous environments that might be able to > quickly use the space as well. > > In a message written on Wed, May 02, 2007 at 01:45:23PM -0700, David > Conrad wrote: > > I'd be happy to write a draft redesignating the class E space if > > somebody can tell me what the consensus is on what it should be > > redesignated to, e.g., "normal" unicast? RFC-1918 extension? Half- > > and-half? Something else? > > It's a two part problem: > > #1 - Write an RFC that software should be updated to treat Class E > space as normal unicast. After all, even 1918 space is just > normal unicast from the perspective of virtually every device > out there. > > #2 - Have the community decide if we want to give this out as > additional 1918 space, full IP unicast space, or some "half > and half" arrangement. We can use the time the vendors are > fixing their code to have that debate. > > Since you volunteered, please write #1 ASAP. :) It will spur people to > have the conversation in #2 much quicker. > > -- > 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 alh-ietf at tndh.net Thu May 3 13:09:09 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 3 May 2007 10:09:09 -0700 Subject: [ppml] 240/4 In-Reply-To: <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> Message-ID: <010101c78da5$c3c5d130$4b517390$@net> Andy Davidson wrote: > On 2 May 2007, at 21:43, Tony Hain wrote: > > > It is worth writing it up for Greenfield deployments of closed > > systems that will not need to include any of the Win9x systems that > > will continue to be in use. > > Yes they are, but we are talking about being ready for 2012, when the > Win9x base of systems will be old enough to marry without permission > (in the UK). "Modern" (by today's standard) OSes can be patched. There is a vast difference between 'can' and 'will'. Win9x -can- be patched, though it is not likely that anyone would bother to do the necessary testing to find any hidden problems. The point is that even -if- MSFT posted an update for every OS version they have ever shipped, they would not be deployed in sufficient numbers to matter. The only people that actually update their systems are the technical elite that are not afraid of breaking the system beyond repair. The only way to weed out the old systems is to have device failures where the cost of repair exceeds the cost of buying a new system along with updated versions of all the software and the consultant that has to migrate all the data to the new format of that is probably 3+ revisions behind. Even then people balk because they don't want to learn something slightly different. Tony From alh-ietf at tndh.net Thu May 3 13:29:02 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 3 May 2007 10:29:02 -0700 Subject: [ppml] 240/4 In-Reply-To: References: Message-ID: <010b01c78da8$8b11a500$a134ef00$@net> michael.dillon wrote: > > In a network like ours, you are talking about a multi year effort. > > In a network like yours you simply filter any 240/4 announcements and > block any 240/4 traffic. > > If the RFC tells people that there MAY be problems routing 240/4 > addresses on the open Internet, and that there MAY be technical > problems > with software or embedded hardware, then that is sufficient. Any RFC > that wants to go beyond that and define specific limitations for 240/4, > such as Greenfield deployments, needs to justify those limitations and > that is hard right now. We simply don't know what will work and what > won't. We also don't know what is easy to fix and what is hard. Better > to just warn people and instruct the RIRs to pass on the warning and > not > misrepresent 240/4 space as problem free. Let the end users decide how > they will use it, and if some future ISPs decide there are no router > issues and let it run on the open Internet, then that is fine. The RFC > writer should not limit these possibilities. You seriously underestimate the problem space by making it sound like simply a routing problem. That space was undefined at the time of testing so every Windows system will not even initiate traffic to that block through the default route because it was not clear if there should have been some other path that was special for that block. Again, don't call MSFT stupid over this, because if they had treated it as just unicast and you wanted to do something else now you would be calling them stupid for ignoring the RFC that said the block was different. It is not a matter of fixing the code, it is about the reality of getting the old systems weeded out of deployment. Joe-sixpack will not spend money on a new system just to appease some obscure policy body. There would have to be a clear value return, and getting those apps deployed will require extensive effort. There is very little reason for a vendor to expend that effort for a short-term hack of using 240/4, when it is clear they will have to turn around and do it all over again to get to IPv6. > > > Yes, from a coding perspective, this is much less than implementing a > new > > stack from scratch. However, from a deployment perspective, it is > still > > less effort than deploying IPv6, but not significantly less. And all > this > > to delay exhaustion by a year 1/2 at best... Not worth it IMHO. > > We don't know the level of effort and we don't know the cost/benefit > ratio because these vary too much from organization to organization. > Our > job is not to be big brother and engineer the runout date, but to act > as > stewards and do all that a reasonable person can do to stave off > exhaustion. Releasing 240/4 for general use is something a reasonable > person would do. Warning people that there MAY be problems is also > something a reasonable person would do. But a reasonable person would > not make an executive decision for everyone in the world that 240/4 is > more trouble than it is worth. I agree that defining it as unicast is a reasonable thing to do. At the same time, doing so requires a serious health warning, calling out the simplest known failure modes at the time. It does not have to be an exhaustive list, but it should be made clear that use of that space has to be for a completely self-contained collection of new end systems with no expectation of it every working to interact with the rest of the IPv4 address space (including 1918). Tony From andy at nosignal.org Thu May 3 13:37:37 2007 From: andy at nosignal.org (Andy Davidson) Date: Thu, 3 May 2007 18:37:37 +0100 Subject: [ppml] 240/4 In-Reply-To: <010101c78da5$c3c5d130$4b517390$@net> References: <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> Message-ID: <20070503173734.GA3124@nosignal.org> On Thu, May 03, 2007 at 10:09:09AM -0700, Tony Hain wrote: > Andy Davidson wrote: > > On 2 May 2007, at 21:43, Tony Hain wrote: > > > It is worth writing it up for Greenfield deployments of closed > > > systems that will not need to include any of the Win9x systems that > > > will continue to be in use. > > Yes they are, but we are talking about being ready for 2012, when the > > Win9x base of systems will be old enough to marry without permission > > (in the UK). "Modern" (by today's standard) OSes can be patched. > There is a vast difference between 'can' and 'will'. Win9x -can- be patched, > though it is not likely that anyone would bother to do the necessary testing > to find any hidden problems. The point is that even -if- MSFT posted an > update for every OS version they have ever shipped, they would not be > deployed in sufficient numbers to matter. The only people that actually Hi, Tony Ok, come 2012 your options for new networks are the old class E networks or v6. End user reachability is important to you. Including to 20 year old operating systems like W9x. We are looking into the future, trying to ensure business has an option when this time comes. Do we decide this year, whilst there is still time to plan for the allocation of 240/4, to buy ourselves time and stand a chance of using this otherwise dead space, or not? I strongly endorse a new rfc to open up 240/4 as routable unicast address space, and am happy to assist in the authoring project. , From paul at vix.com Wed May 2 16:29:36 2007 From: paul at vix.com (Paul Vixie) Date: Wed, 02 May 2007 20:29:36 +0000 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: Your message of "Wed, 02 May 2007 12:52:13 MST." <550F1737-5EC7-477E-A127-587135459C3D@delong.com> References: <4635E419.1030801@neovera.com> <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> <2316.1177975657@sa.vix.com> <550F1737-5EC7-477E-A127-587135459C3D@delong.com> Message-ID: <27823.1178137776@sa.vix.com> > In general, if you are assigning /32s to customer utilization, but, not > to independently routed segments (e.g. you have a bunch of customers > on the same server each assigned a /32), then, no, you don't meet > ARIN's definition of an ISP. i don't think that's true. some of these customers have VNC or PPTP but only for certain udp/tcp port numbers. it's an allocation to an entity other than oneself. if the PTR RR doesn't prove that, then we should tell folks to SWIP such /32's. but fundamentally, the mere fact that there is not a hard network does not mean that these are not downstream allocations. From paul at vix.com Wed May 2 16:47:13 2007 From: paul at vix.com (Paul Vixie) Date: Wed, 02 May 2007 20:47:13 +0000 Subject: [ppml] 240/4 In-Reply-To: Your message of "Wed, 02 May 2007 13:45:23 MST." <45A75C3E-1813-4261-8C78-64CAE0E888C4@virtualized.org> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <45A75C3E-1813-4261-8C78-64CAE0E888C4@virtualized.org> Message-ID: <30643.1178138833@sa.vix.com> > I'd be happy to write a draft redesignating the class E space if > somebody can tell me what the consensus is on what it should be > redesignated to, e.g., "normal" unicast? RFC-1918 extension? Half- > and-half? Something else? rfc 1918 extension. From Paul_Vixie at isc.org Thu May 3 09:46:37 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Thu, 03 May 2007 13:46:37 +0000 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: Your message of "Thu, 03 May 2007 02:20:38 MST." References: <4635E419.1030801@neovera.com><0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca><2316.1177975657@sa.vix.com> <550F1737-5EC7-477E-A127-587135459C3D@delong.com> Message-ID: <25818.1178199997@sa.vix.com> > From an ARIN perspective, reassignments apply to networks, not to host > addresses. that's just not true. From schiller at uu.net Thu May 3 17:48:09 2007 From: schiller at uu.net (Jason Schiller) Date: Thu, 03 May 2007 17:48:09 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <463253DC.4010609@bogomips.com> Message-ID: On Fri, 27 Apr 2007, John Paul Morrison wrote: > I don't know how this would lead to a run on IPv4 space, because I have > had to justify several /24's for > customers - allocated out of Carriers/Telco IP address space to be used > for BGP multi-homing. > It's a hassle, you are tied to one carrier's address space, and you > have more dependence on the carrier's BGP policies than if you had your > own /24. > I would prefer to have a direct allocation, but whether I get a /24 from > a carrier or ARIN, doesn't > really change the address consumption. They way I read the policy, and the way I understand how most ISP do PA assignemtns, is if a customer is multi-homed even with a very limited number of hosts they will qualify for a /24. In otherwords, a single homed static customer with 10 hosts could be assigned a /28. The same customer who is multi-homed would be assigned a /24. This consumes more space. Also there was a concern about spammers. Spammers tend to get their address space black listed rather quickly. Often times they will start a new company, get new address space, get it black listed with in a month or so, and then start the process over with a new company and new addresses. This could burn through a lot of resources quickly (both IPv4 PI /24s and ASNs). Furthmore reclaiming the resources will be problematic as it will be listed in ACLs and RBLs. This will be akin to the same difficulty people have when they are allocated / assigned space that was previously bogon space, and hence, no one will want pre-spammer IP space due to the significant clean-up work involved. This is why I would be more agreeable with a policy that required a site to actually be multi-homed for 6 months before they would qualify for their own PI address space. (although I suspect it would be hard for me to support any policy that increases the routing table at this point). > > The requirement for a /24 to do BGP multi-homing is basically arbitrary, > but it dates back to concerns > about routing table size. If you could convince the majority of ISPs and > AS's that /25's or even longer > prefixes belong in the global routing tables, then you could come up > with a workable IPv4 multi-homing > solution that doesn't require a /24 allocation. However in practice, > longer prefixes may not be routable. > > Perhaps the wording of 2007-6 should be changed to remove the reference > to a /24 allocation and focus > on the actual need. Routing table bloat is a concern, but I'm not sure > it's as big an issue as it once was 5 or 10 years ago. > If routing table size is really a problem, it's going to be made worse > with IPv6, since that's going to cause > more growth. (I'm sure you can have an efficient IPv6+IPv4 RIB in > backbone routers, but IPv6 will only add routing > entries, and at that point, who cares whether a route is an IPv6 /48 or > an IPv4 /28?) Yes what we are talking about here is the amount of RIB and FIB memory consumed. In short there are a limited number of routing slots, and IPv6 prefixes take up more memory than IPv4 prefixes. Routing table bloat is a big concern. It is a concern in IPv4, it is a concern in IPv6, and it is a concern in a dual stack environment. Because of the current concern about routing table size, there is no clear consensus among ISPs if they will listen to /48 IPv6 PI addresses (or even /48 IPv6 PA more specifics) from multi-homed destinations of Peers. So I am not sure I buy your arguement of things are going to get really bad when IPv6 mult-homing happens, so we might as well let some extra IPv4 PI /24s in the table now. This to me sounds similar to the arguement that we are running out of IPv4 addresses so we should just speed this process along by giving out addresses to anyone who asks. My concern is that it will increase the number of prefixes in the table. A customer with 10 hosts and no need for multi-homing needs only an IPv4 PA /28. That IPv4 PA /28 does not show up in the global routing table as it is aggregated into the the PA aggregate (say a /12). That single prefix (/12) in the routing table can represent many (65,535 /28s) small customers. Now if some percentage of customers have no need for multi-homing but want their own provider independant IPv4 space, then they may multi-home long enough to get their own block. Say for example it may be more cost effective to purchase a seccond Internet connection for one year in order to get their own PI addresses rather than the cost of eventual renumbering. In one years time when they stop multi-homing, the routing system will still be required to carry the extra /24 as it cannot be aggregated into a PA block. It might be interesting to study what addresses are assigned under the multi-homing policy, and see what percentage of these blocks (and their associated ASN) appear to still be multi-homed one, two, or three years after the assignment is made. > > If ARIN sets aside some space specifically for multi-homed ASs, which is > allowed to have /25 or longer allocations, carriers > can still filter the rest of the routing table to restrict more specific > routes, and can make exceptions for this > address space. But the technical challenges will have to be addressed by > the carriers and end users, because > prefixes longer than /24 could easily be non-routable. It seems unfair to have different policies for PI multi-homers and PA multi-homers. Not everybody wants PI addresses. If PI /25s are allowed to consume a slot in the global routing table, then current PA mutli-homers will want to be able to divide the PA /24 in two /25s to gain more control over thier in-bound traffic loading. Likewise if ISPs start listening to IPv6 PI /48s from Peers, then they should also listen to IPv6 PA /48s from Peers. After all if it is acceptable for a PI multi-homer to consume one slot in the global routing table, then it should also be acceptable for a PA mutli-homer to do the same. Then is goes to follow that more than one slot should be allowed to enable destinations to control their inbound traffic loading... And we end up doing IPv6 multi-homing exactly how we are doing IPv4 multi-homing. While there are not a ot of prefixes int eh IPv6 routing table at the moment, once wide spread adoption happens this will no longer be true. I suspect it will me much more difficult to tighten the belt in the future. So a decesion now to allow deaggregation to support multi-homing is likely to be a long term commitment to deagragation in order to support multi-homing... So what does a long term commitment to deagragation look like? Well, lets first try to understand how big the routing tabel would be if everyone adopted IPv6 and moved to a dual stack enviorment tomarrow, and then project out from there to some future point. Here is some quick math on the routing table problem: The CIDR Report: Date Prefixes CIDR Aggregated 04-05-07 216692 139633 24992 Number of ASes in routing system 1. The IPv4 Internet table is 216,692 routes 2. The IPv4 Internet table can be aggrgeated down to 139633, which means that there are (216692 - 139633) 77,059 intentional more specifics for multi-homing and TE and such. 3. If everyone did dual stack tomarrow (I know there will be a ramp up), they waould have one aggregate for each site (ASN) 24,992 4. If we did multi-homneing and TE in IPv6 the same a swe do for IPv4 we would have 77,059 intentional more specifics for multi-homing and TE. 5. If everyone did dual staick tomarrow the IPv6 Internet would be (24,992 + 77,059) 102,051 routes. 6. add to that the internal IPv4 more specific routes of a large ISP say 150,000 routes. 7. add to that the internal IPv6 more specific routes of a large ISP say 120,000 routes 8. you end up with a total routing table of about (216,692 + 102,051 + 150,000 + 120,000) 588,743 routes. Now if you think IPv4 exhaustion might happen by Jan 1, 2010, and expect wide spread IPv6 adoption to follow right behind that then you can project the routing table will be about a 800,000 If you think IPv4 exhaustion might happen by June 12, 2012, and expect wide spread IPv6 adoption to follow right behind that then you can project the routing table will be about 1.2 million routes Now add to this all of the extra prefixes from sites that start to multi-home just to get PI space, and all of the /24s that are leased out of legacy /8 space, and evry third household in China being multi-homed, and every item in Wal*Mart havig a RFID tag with an IPv6 address, and ... __Jason > > > John Paul Morrison > > > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From bicknell at ufp.org Thu May 3 17:48:57 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 3 May 2007 17:48:57 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <463A0FE8.7000106@kl.net> References: <550F1737-5EC7-477E-A127-587135459C3D@delong.com> <463A0FE8.7000106@kl.net> Message-ID: <20070503214856.GA91125@ussenterprise.ufp.org> In a message written on Thu, May 03, 2007 at 12:38:00PM -0400, Kevin Loch wrote: > There is a public benefit to have anyone who is actually providing > Internet services to be considered an ISP under ARIN policy. This does > not mean that they would automatically meed the minimum requirements > for a delegation from ARIN but if they do they should not be considered > an end site. I'm curious about the public benefit portion of your statement. I suspect a number of very small ISP's, providing only dynamicly assigned services, or running ASP type services would much prefer to be treated by ARIN as end users. For small users, 25% initial utilization is much larger than a 6 month supply, and in many situation is cheaper as well. Since the customers are dynamic and/or they are running server based infrastructure there's no real benefit to SWIP records, since they are doing to be the point of contact anyway. Where do you see there's benefit, in particular public? -- 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 kloch at kl.net Thu May 3 18:34:01 2007 From: kloch at kl.net (Kevin Loch) Date: Thu, 03 May 2007 18:34:01 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <20070503214856.GA91125@ussenterprise.ufp.org> References: <550F1737-5EC7-477E-A127-587135459C3D@delong.com> <463A0FE8.7000106@kl.net> <20070503214856.GA91125@ussenterprise.ufp.org> Message-ID: <463A6359.5030900@kl.net> Leo Bicknell wrote: > I'm curious about the public benefit portion of your statement. I > suspect a number of very small ISP's, providing only dynamicly > assigned services, or running ASP type services would much prefer > to be treated by ARIN as end users. For small users, 25% initial > utilization is much larger than a 6 month supply, and in many > situation is cheaper as well. Since the customers are dynamic > and/or they are running server based infrastructure there's no real > benefit to SWIP records, since they are doing to be the point of > contact anyway. > > Where do you see there's benefit, in particular public? I was thinking in terms of publishing reassignment information. Of course for those only assigning > /29 and/or not needing to ever come back for more addresses that isn't a factor. - Kevin From owen at delong.com Thu May 3 18:57:05 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 3 May 2007 15:57:05 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: References: Message-ID: ** Leslie -- Look about half way down for a statistical request. Thx, Owen On May 3, 2007, at 2:48 PM, Jason Schiller wrote: > On Fri, 27 Apr 2007, John Paul Morrison wrote: > >> I don't know how this would lead to a run on IPv4 space, because I >> have >> had to justify several /24's for >> customers - allocated out of Carriers/Telco IP address space to be >> used >> for BGP multi-homing. >> It's a hassle, you are tied to one carrier's address space, and you >> have more dependence on the carrier's BGP policies than if you had >> your >> own /24. >> I would prefer to have a direct allocation, but whether I get a / >> 24 from >> a carrier or ARIN, doesn't >> really change the address consumption. > > They way I read the policy, and the way I understand how most ISP > do PA > assignemtns, is if a customer is multi-homed even with a very limited > number of hosts they will qualify for a /24. In otherwords, a single > homed static customer with 10 hosts could be assigned a /28. The same > customer who is multi-homed would be assigned a /24. This consumes > more > space. > You need to reread the policy. The policy as written would still require the user to meet the 50% utilization threshold for initial assignment and would require an 80% utilization for any ability to get additional assignment(s). > Also there was a concern about spammers. Spammers tend to get their > address space black listed rather quickly. Often times they will > start a > new company, get new address space, get it black listed with in a > month or > so, and then start the process over with a new company and new > addresses. > This could burn through a lot of resources quickly (both IPv4 PI / > 24s and > ASNs). > It was pointed out that it's easier for Spammers to cycle resources like this through ISPs than through ARIN and there was no reason to believe that any spammer who would make use of this through ARIN is not already doing so using /22s. As such, I consider this argument specious at best and rather like FUD. > Furthmore reclaiming the resources will be problematic as it will be > listed in ACLs and RBLs. This will be akin to the same difficulty > people > have when they are allocated / assigned space that was previously > bogon > space, and hence, no one will want pre-spammer IP space due to the > significant clean-up work involved. > This is true in the PA world as well, yet, somehow it seems to end up working out. I don't see a difference for these arguments between PI and PA. > This is why I would be more agreeable with a policy that required a > site > to actually be multi-homed for 6 months before they would qualify for > their own PI address space. (although I suspect it would be hard > for me > to support any policy that increases the routing table at this point). > The policy proposal I submitted (and recently revised with Stephen Sprunk) is an attempt to address this on a more global basis than just this policy. Given that you have already stated that any user who would qualify under this policy (and then some) would have a slot in the global routing table for their PA space, I'm not sure I understand how this increases the routing table. Could you please explain that? >> >> The requirement for a /24 to do BGP multi-homing is basically >> arbitrary, >> but it dates back to concerns >> about routing table size. If you could convince the majority of >> ISPs and >> AS's that /25's or even longer >> prefixes belong in the global routing tables, then you could come up >> with a workable IPv4 multi-homing >> solution that doesn't require a /24 allocation. However in practice, >> longer prefixes may not be routable. >> >> Perhaps the wording of 2007-6 should be changed to remove the >> reference >> to a /24 allocation and focus >> on the actual need. Routing table bloat is a concern, but I'm not >> sure >> it's as big an issue as it once was 5 or 10 years ago. >> If routing table size is really a problem, it's going to be made >> worse >> with IPv6, since that's going to cause >> more growth. (I'm sure you can have an efficient IPv6+IPv4 RIB in >> backbone routers, but IPv6 will only add routing >> entries, and at that point, who cares whether a route is an IPv6 / >> 48 or >> an IPv4 /28?) > > Yes what we are talking about here is the amount of RIB and FIB memory > consumed. In short there are a limited number of routing slots, > and IPv6 > prefixes take up more memory than IPv4 prefixes. Routing table > bloat is a > big concern. It is a concern in IPv4, it is a concern in IPv6, and > it is > a concern in a dual stack environment. > It is a reality regardless of what we do here. In fact, I would argue that any assignments this policy would provide beyond what are already available from PA /24s and PI /22s would be well inside the noise floor. > Because of the current concern about routing table size, there is > no clear > consensus among ISPs if they will listen to /48 IPv6 PI addresses > (or even > /48 IPv6 PA more specifics) from multi-homed destinations of > Peers. So I > am not sure I buy your arguement of things are going to get really bad > when IPv6 mult-homing happens, so we might as well let some extra > IPv4 PI > /24s in the table now. This to me sounds similar to the arguement > that we > are running out of IPv4 addresses so we should just speed this process > along by giving out addresses to anyone who asks. > What's the difference between a multihomed PI v4 and PA v4 from a routing table perspective? It's still the same sized slot and the same amount of memory. > > My concern is that it will increase the number of prefixes in the > table. A customer with 10 hosts and no need for multi-homing needs > only > an IPv4 PA /28. That IPv4 PA /28 does not show up in the global > routing > table as it is aggregated into the the PA aggregate (say a /12). That > single prefix (/12) in the routing table can represent many > (65,535 /28s) > small customers. > A customer with 10 hosts wouldn't qualify under the proposed policy. My math makes me think that to meet the 50% threshold for a /24, you would need at least 63 hosts (126 available host addresses divided by 2 (50%) is 63, right?). Despite this fact, you aboveclaimed that these customers who DO multihome receive a /24 and get a slot in the routing table anyway from their providers. At least the policy as proposed seems to be better for the global routing table than your description of current ISP practices. > Now if some percentage of customers have no need for multi-homing > but want > their own provider independant IPv4 space, then they may multi-home > long > enough to get their own block. Say for example it may be more cost > effective to purchase a seccond Internet connection for one year in > order > to get their own PI addresses rather than the cost of eventual > renumbering. In one years time when they stop multi-homing, the > routing > system will still be required to carry the extra /24 as it cannot be > aggregated into a PA block. > True. However, there is existing policy to address that, and, a policy proposal designed to make it even easier for ARIN to revoke resources under such circumstances. ****** Leslie -- Here's the request... > It might be interesting to study what addresses are assigned under the > multi-homing policy, and see what percentage of these blocks (and > their > associated ASN) appear to still be multi-homed one, two, or three > years > after the assignment is made. > Well, 3 years will require us to wait some time for the /22s, but, I'd agree. I've CC'd Leslie on this message. Hopefully she'll chime in with the statistics. >> >> If ARIN sets aside some space specifically for multi-homed ASs, >> which is >> allowed to have /25 or longer allocations, carriers >> can still filter the rest of the routing table to restrict more >> specific >> routes, and can make exceptions for this >> address space. But the technical challenges will have to be >> addressed by >> the carriers and end users, because >> prefixes longer than /24 could easily be non-routable. > > It seems unfair to have different policies for PI multi-homers and PA > multi-homers. Not everybody wants PI addresses. If PI /25s are > allowed > to consume a slot in the global routing table, then current PA > mutli-homers will want to be able to divide the PA /24 in two /25s > to gain > more control over thier in-bound traffic loading. > I agree. I'm not a big fan of that approach either, and, I'm not necessarily in favor of moving the bit boundary further to the right than /24. > Likewise if ISPs start listening to IPv6 PI /48s from Peers, then they > should also listen to IPv6 PA /48s from Peers. After all if it is > acceptable for a PI multi-homer to consume one slot in the global > routing > table, then it should also be acceptable for a PA mutli-homer to do > the > same. Then is goes to follow that more than one slot should be > allowed to > enable destinations to control their inbound traffic loading... > Yep. Eventually, you come to realize that the current method of routing is just plain broken and that we need to start routing on something other than prefix in the IDR world. > And we end up doing IPv6 multi-homing exactly how we are doing IPv4 > multi-homing. While there are not a ot of prefixes int eh IPv6 > routing > table at the moment, once wide spread adoption happens this will no > longer > be true. > Yep. > I suspect it will me much more difficult to tighten the belt in the > future. So a decesion now to allow deaggregation to support multi- > homing > is likely to be a long term commitment to deagragation in order to > support > multi-homing... > As well it should be. Further, long term deaggregation is the reality we simply need to accept. It's going to happen. Aggregation is selling in today's market about as well as DiVX did against DVDs for many of the same reasons. Consumers just don't like the limitations it imposes on their freedom of choice. > So what does a long term commitment to deagragation look like? > Well, lets > first try to understand how big the routing tabel would be if everyone > adopted IPv6 and moved to a dual stack enviorment tomarrow, and then > project out from there to some future point. > Instead, let's admit that a long term commitment to deaggregation comes with a long term commitment to fixing the routing process. > > Now add to this all of the extra prefixes from sites that start to > multi-home just to get PI space, and all of the /24s that are > leased out > of legacy /8 space, and evry third household in China being multi- > homed, > and every item in Wal*Mart havig a RFID tag with an IPv6 address, > and ... > Do you have any data to support the assertion that sites will multihome just to get PI space? I would assert that a large portion of sites will get PI space just to make their multihoming choices easier rather than the other way around. If I'm willing to lie to get PI space by temporarily multihoming for that purpose, then, I can just tell a slightly bigger lie and get a /22 now. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From bmanning at karoshi.com Thu May 3 21:44:49 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Fri, 4 May 2007 01:44:49 +0000 Subject: [ppml] 240/4 In-Reply-To: <20070503173734.GA3124@nosignal.org> References: <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> Message-ID: <20070504014449.GA11286@vacation.karoshi.com.> > > I strongly endorse a new rfc to open up 240/4 as routable > unicast address space, and am happy to assist in the authoring > project. > > , again, if you think this is useful idea, TRY IT OUT. then document the effects and what needs to be changed before writing a wellmeaning but worthless document. i suggest that you attempt to use 240.240.240.0/24 on a subnet in your local infrastructure and then tell us the results. a more interesting case is when you route between 240.240.240.0/24 and 240.77.77.0/24 ... real data would be most helpful in this debate. in my case: # ifconfig eth1 240.240.42.14 SIOCSIFADDR: Invalid argument on a couple of Linux 2.4.x kernels. (old i know) --bill From dlw+arin at tellme.com Thu May 3 23:27:39 2007 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 3 May 2007 20:27:39 -0700 Subject: [ppml] 240/4 In-Reply-To: <20070504014449.GA11286@vacation.karoshi.com.> References: <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> Message-ID: <20070504032739.GR22657@shell01.corp.tellme.com> On Fri, May 04, 2007 at 01:44:49AM +0000, bmanning at karoshi.com wrote: > i suggest that you attempt to use 240.240.240.0/24 > on a subnet in your local infrastructure and then tell us > the results. a more interesting case is when you route > between 240.240.240.0/24 and 240.77.77.0/24 ... real data > would be most helpful in this debate. Well, that's easy enough: root at host15:~# uname -a SunOS host15 5.10 Generic_118855-19 i86pc i386 i86pc root at host15:~# ifconfig iprb1 240.240.42.14 ifconfig: SIOCSLIFADDR: iprb1: Cannot assign requested address -David From michel at arneill-py.sacramento.ca.us Thu May 3 23:38:37 2007 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 3 May 2007 20:38:37 -0700 Subject: [ppml] 240/4 In-Reply-To: References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> Message-ID: David, Thanks for correcting my poor English! > David Conrad wrote: > The cost of redesignating class E space is the cost > of writing an RFC, IANA editing a file, and IANA > publishing that file on IANA's web site. > ..[snip].. > The cost of utilizing class E space will likely be > significantly higher. I don't think the IETF and/or IANA should go forward with redesignating class E, because too many will assume that redesignated == useable at nominal cost. You know, the old "perception is reality" thing. > However, if you judge the cost of utilization high, don't > use it. That is, "Doctor, it hurts when I do this..." That is the kind of irresponsible behavior (redesignating without any concerns of cost or deployability) that the IETF unfortunately has a lot of experience with. Michel. From Alain_Durand at cable.comcast.com Fri May 4 03:31:45 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Fri, 4 May 2007 03:31:45 -0400 Subject: [ppml] 240/4 In-Reply-To: <20070504032739.GR22657@shell01.corp.tellme.com> Message-ID: I just tried on my windows XP pro laptop to manually configure the interface. When I entered 240., I got a pop up window that told me that 240 was not a valid entry, I should use a value between 1 and 223. - Alain. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David Williamson > Sent: Thursday, May 03, 2007 11:28 PM > To: bmanning at karoshi.com > Cc: 'Public Policy Mailing List' > Subject: Re: [ppml] 240/4 > > On Fri, May 04, 2007 at 01:44:49AM +0000, bmanning at karoshi.com wrote: > > i suggest that you attempt to use 240.240.240.0/24 > > on a subnet in your local infrastructure and then tell us > > the results. a more interesting case is when you route > > between 240.240.240.0/24 and 240.77.77.0/24 ... real data > > would be most helpful in this debate. > > Well, that's easy enough: > > root at host15:~# uname -a > SunOS host15 5.10 Generic_118855-19 i86pc i386 i86pc > root at host15:~# ifconfig iprb1 240.240.42.14 > ifconfig: SIOCSLIFADDR: iprb1: Cannot assign requested address > > -David > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From michael.dillon at bt.com Fri May 4 03:40:24 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 4 May 2007 08:40:24 +0100 Subject: [ppml] 240/4 In-Reply-To: <010b01c78da8$8b11a500$a134ef00$@net> References: <010b01c78da8$8b11a500$a134ef00$@net> Message-ID: > > If the RFC tells people that there MAY be problems routing 240/4 > > addresses on the open Internet, and that there MAY be technical > > problems > You seriously underestimate the problem space by making it sound like > simply > a routing problem. No I don't! This is not a technical mailing list and there is no need to get into such technical details here. In fact, an RFC that releases 240/4 from bondage also does not need to directly address these technical issues, merely point out that there MAY be problems and that there is need for further work, an maybe future RFCs to cover those issues. > That space was undefined at the time of testing so > every > Windows system will not even initiate traffic to that block through the > default route because it was not clear if there should have been some > other > path that was special for that block. Windows software is regularly patched, more often than server software in my experience. I am not concerned about any specific behaviour in Windows because I know that once the 240/4 RFC goes out, MS will be motivated to fix them. > It is not a matter of fixing the code, it is about the reality of getting > the old systems weeded out of deployment. That is an issue for the organizations that decide they want to try using the newly available 240/4 space. I am not going to try and second guess their motives or how they might deploy the space. Networks are not as homogenous as you imagine. The RFC that releases 240/4 is not directed at Joe Sixpack which is why the RIRs will be instructed to warn applicants an get them to state that they are aware of the technical problems with 240/4. > but it should be made clear that use of that space has to be for a > completely self-contained collection of new end systems with no > expectation > of it every working to interact with the rest of the IPv4 address space > (including 1918). The RFC should not say that the 240/4 space MUST be used for a self-contained deployment, but it SHOULD warn that this MAY be the only useful way of using such addresses. --Michael Dillon From Alain_Durand at cable.comcast.com Fri May 4 04:43:36 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Fri, 4 May 2007 04:43:36 -0400 Subject: [ppml] 256/3 was Re: 240/4 Message-ID: In the spirit of "let's write an RFC to free up some space and the problem will go away", I would like to suggest to write an RFC opening up 256/3. That would free up 64 new /8, enough to delay IPv4 exhaustion by several years. And if we still ran out after that, we can later on open up the next block, 320/3. Oh, it has been reported that many systems today do not support those addresses, but this is clearly a software update issue that can be addressed by a simple patch, and anyway by the time that space will be needed, all those legacy systems will be retired. Of course, greenfield deployment will have no problem using it today. - Alain. ----- Original Message ----- From: ppml-bounces at arin.net To: ppml at arin.net Sent: Fri May 04 03:40:24 2007 Subject: Re: [ppml] 240/4 > > If the RFC tells people that there MAY be problems routing 240/4 > > addresses on the open Internet, and that there MAY be technical > > problems > You seriously underestimate the problem space by making it sound like > simply > a routing problem. No I don't! This is not a technical mailing list and there is no need to get into such technical details here. In fact, an RFC that releases 240/4 from bondage also does not need to directly address these technical issues, merely point out that there MAY be problems and that there is need for further work, an maybe future RFCs to cover those issues. > That space was undefined at the time of testing so > every > Windows system will not even initiate traffic to that block through the > default route because it was not clear if there should have been some > other > path that was special for that block. Windows software is regularly patched, more often than server software in my experience. I am not concerned about any specific behaviour in Windows because I know that once the 240/4 RFC goes out, MS will be motivated to fix them. > It is not a matter of fixing the code, it is about the reality of getting > the old systems weeded out of deployment. That is an issue for the organizations that decide they want to try using the newly available 240/4 space. I am not going to try and second guess their motives or how they might deploy the space. Networks are not as homogenous as you imagine. The RFC that releases 240/4 is not directed at Joe Sixpack which is why the RIRs will be instructed to warn applicants an get them to state that they are aware of the technical problems with 240/4. > but it should be made clear that use of that space has to be for a > completely self-contained collection of new end systems with no > expectation > of it every working to interact with the rest of the IPv4 address space > (including 1918). The RFC should not say that the 240/4 space MUST be used for a self-contained deployment, but it SHOULD warn that this MAY be the only useful way of using such addresses. --Michael Dillon _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From michael.dillon at bt.com Fri May 4 05:16:08 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 4 May 2007 10:16:08 +0100 Subject: [ppml] 240/4 In-Reply-To: <20070504014449.GA11286@vacation.karoshi.com.> References: <462CAEF0.1040804@arin.net><85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org><00ff01c78cfa$84cb5820$8e620860$@net><07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org><010101c78da5$c3c5d130$4b517390$@net><20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> Message-ID: > again, if you think this is useful idea, TRY IT OUT. > then document the effects and what needs to be changed > before writing a wellmeaning but worthless document. Trying it out, only results in documenting the current state of affairs. It is more important to set the stage for future work than to document current technical details. We already know that current software cripples 240/4 addresses. That is not an issue. The purpose of the RFC is to get 240/4 addresses *OUT* of reserved status and back into play. > i suggest that you attempt to use 240.240.240.0/24 > on a subnet in your local infrastructure and then tell us > the results. This is useless info. The people who should be trying 240/4 will be those who have access to system source code so that they can identify what needs to be patched to enable 240/4 to work. Obviously, they don't need an RFC to get permission to do the work, but if an RFC *DID* release 240/4 from purgatory, I have no doubt that many such people will do the work. > # ifconfig eth1 240.240.42.14 > SIOCSIFADDR: Invalid argument > > on a couple of Linux 2.4.x kernels. (old i know) Useless info. What code did you patch to fix this? What variable did you create in the /proc filesystem to enable/disable use of 240/4 addresses? --Michael Dillon From bmanning at karoshi.com Fri May 4 07:03:25 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Fri, 4 May 2007 11:03:25 +0000 Subject: [ppml] 240/4 In-Reply-To: References: <20070504014449.GA11286@vacation.karoshi.com.> Message-ID: <20070504110325.GC14166@vacation.karoshi.com.> On Fri, May 04, 2007 at 10:16:08AM +0100, michael.dillon at bt.com wrote: > > > > again, if you think this is useful idea, TRY IT OUT. > > then document the effects and what needs to be changed > > before writing a wellmeaning but worthless document. > > Trying it out, only results in documenting the current state of affairs. you have to start someplace. > It is more important to set the stage for future work than to document > current technical details. We already know that current software > cripples 240/4 addresses. That is not an issue. The purpose of the RFC > is to get 240/4 addresses *OUT* of reserved status and back into play. i never said it was an issue, i simply stated that it would be nice to know the magnitude of the problem space. > > > i suggest that you attempt to use 240.240.240.0/24 > > on a subnet in your local infrastructure and then tell us > > the results. > > This is useless info. The people who should be trying 240/4 will be > those who have access to system source code so that they can identify > what needs to be patched to enable 240/4 to work. Obviously, they don't > need an RFC to get permission to do the work, but if an RFC *DID* > release 240/4 from purgatory, I have no doubt that many such people will > do the work. your faith in coders and thier manaagers is a joy to behold. the reason i posted my Linux example is that I HAVE the source code. I don't have the code for cisco, linksys, airport, or macOS, or (fill in the blanks)... my original take on this problem is that it could (and should) be treated like the original CIDR problem. at that time, certain netblocks were considered "reserved" and hardcoded as not usable. The net 39 experiment was to shake out the scope of the problem space, what needed to be changed in the protocol processing stacks to ensure the address space would be useful... BEFORE releasing the address space into use. to be fair, i want a "punch-list" of things that don't work w/ these addresses - then there are concrete steps that can be taken to try and sell the idea to these folks that it is useful/prudent to spend the money to change their code in future. otherwise, i think this is wishful thinking. > > > # ifconfig eth1 240.240.42.14 > > SIOCSIFADDR: Invalid argument > > > > on a couple of Linux 2.4.x kernels. (old i know) > > Useless info. What code did you patch to fix this? What variable did you > create in the /proc filesystem to enable/disable use of 240/4 addresses? i've not patched it yet. this is stock RedHat/Debian base. when/if I do, i'll share w/ the developers and see if they wish to make the changes. > > --Michael Dillon > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From Kavalec at BSWA.com Fri May 4 09:30:37 2007 From: Kavalec at BSWA.com (G. Waleed Kavalec) Date: Fri, 4 May 2007 07:30:37 -0600 Subject: [ppml] Policy Proposal 2007-6 - Abandoned Message-ID: > Spammers tend to get their address space black listed rather quickly. > Often times they will start a new company, get new address space, get > it black listed with in a month or so, and then start the process over > with a new company and new addresses. This could burn through a lot > of resources quickly (both IPv4 PI /24s and ASNs). Is this still true? Haven't most spammers moved on to the use of botnets? -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jason Schiller Sent: Thursday, May 03, 2007 3:48 PM To: John Paul Morrison Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-6 - Abandoned On Fri, 27 Apr 2007, John Paul Morrison wrote: > I don't know how this would lead to a run on IPv4 space, because I have > had to justify several /24's for > customers - allocated out of Carriers/Telco IP address space to be used > for BGP multi-homing. > It's a hassle, you are tied to one carrier's address space, and you > have more dependence on the carrier's BGP policies than if you had your > own /24. > I would prefer to have a direct allocation, but whether I get a /24 from > a carrier or ARIN, doesn't > really change the address consumption. They way I read the policy, and the way I understand how most ISP do PA assignemtns, is if a customer is multi-homed even with a very limited number of hosts they will qualify for a /24. In otherwords, a single homed static customer with 10 hosts could be assigned a /28. The same customer who is multi-homed would be assigned a /24. This consumes more space. Also there was a concern about spammers. Spammers tend to get their address space black listed rather quickly. Often times they will start a new company, get new address space, get it black listed with in a month or so, and then start the process over with a new company and new addresses. This could burn through a lot of resources quickly (both IPv4 PI /24s and ASNs). Furthmore reclaiming the resources will be problematic as it will be listed in ACLs and RBLs. This will be akin to the same difficulty people have when they are allocated / assigned space that was previously bogon space, and hence, no one will want pre-spammer IP space due to the significant clean-up work involved. From bicknell at ufp.org Fri May 4 09:06:20 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 4 May 2007 09:06:20 -0400 Subject: [ppml] 240/4 In-Reply-To: <20070504014449.GA11286@vacation.karoshi.com.> References: <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> Message-ID: <20070504130620.GA28372@ussenterprise.ufp.org> In a message written on Fri, May 04, 2007 at 01:44:49AM +0000, bmanning at karoshi.com wrote: > again, if you think this is useful idea, TRY IT OUT. > then document the effects and what needs to be changed > before writing a wellmeaning but worthless document. Below are patches for FreeBSD 5.4-RELEASE. Not fully tested, but I post them to show the magnitude of the change. The first patch is all that's necessary to enable "Class E" space. The second patch is purely cleanup to keep the code neat and tidy. I suspect the level of effort for any Unix based platform is similar, and since new Windows lifted much of the BSD networking code it's probably fairly similar over there. For all the vendor moaning about this, the patch here amounts to deleting 23 characters on a single line and recompiling. If it's not that simple for other vendors, they deserve all the pain they get over it, because they wrote crappy code in the first place. *** /usr/src/sys/netinet/in.c.orig Fri May 4 08:58:07 2007 --- /usr/src/sys/netinet/in.c Fri May 4 08:58:56 2007 *************** *** 127,133 **** register u_long i = ntohl(in.s_addr); register u_long net; ! if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i)) return (0); if (IN_CLASSA(i)) { net = i & IN_CLASSA_NET; --- 127,133 ---- register u_long i = ntohl(in.s_addr); register u_long net; ! if (IN_MULTICAST(i)) return (0); if (IN_CLASSA(i)) { net = i & IN_CLASSA_NET; *** /usr/src/sys/netinet/in.h.orig Fri May 4 08:58:10 2007 --- /usr/src/sys/netinet/in.h Fri May 4 08:58:38 2007 *************** *** 341,349 **** #define IN_CLASSD_HOST 0x0fffffff /* routing needn't know. */ #define IN_MULTICAST(i) IN_CLASSD(i) - #define IN_EXPERIMENTAL(i) (((u_int32_t)(i) & 0xf0000000) == 0xf0000000) - #define IN_BADCLASS(i) (((u_int32_t)(i) & 0xf0000000) == 0xf0000000) - #define INADDR_LOOPBACK (u_int32_t)0x7f000001 #ifndef _KERNEL #define INADDR_NONE 0xffffffff /* -1 return */ --- 341,346 ---- -- 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 vixie at vix.com Fri May 4 10:15:52 2007 From: vixie at vix.com (vixie at vix.com) Date: Fri, 04 May 2007 14:15:52 +0000 Subject: [ppml] 240/4 In-Reply-To: Your message of "Fri, 04 May 2007 09:06:20 -0400." <20070504130620.GA28372@ussenterprise.ufp.org> References: <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> <20070504130620.GA28372@ussenterprise.ufp.org> Message-ID: <84942.1178288152@sa.vix.com> > *** /usr/src/sys/netinet/in.h.orig Fri May 4 08:58:10 2007 > --- /usr/src/sys/netinet/in.h Fri May 4 08:58:38 2007 > *************** > *** 341,349 **** > - #define IN_EXPERIMENTAL(i) (((u_int32_t)(i) & 0xf0000000) == 0xf0000000) > - #define IN_BADCLASS(i) (((u_int32_t)(i) & 0xf0000000) == 0xf0000000) you can't remove these macros. just make them always-return-zero. From kloch at kl.net Fri May 4 10:23:57 2007 From: kloch at kl.net (Kevin Loch) Date: Fri, 04 May 2007 10:23:57 -0400 Subject: [ppml] 240/4 In-Reply-To: <20070504014449.GA11286@vacation.karoshi.com.> References: <462CAEF0.1040804@arin.net> <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> Message-ID: <463B41FD.5070300@kl.net> bmanning at karoshi.com wrote: > in my case: > > # ifconfig eth1 240.240.42.14 > SIOCSIFADDR: Invalid argument > > on a couple of Linux 2.4.x kernels. (old i know) FreeBSD 6.2 lets you configure it, but it drops packets on the floor. At least we have the source for Linux/BSD. - Kevin From michel at arneill-py.sacramento.ca.us Fri May 4 11:42:13 2007 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 4 May 2007 08:42:13 -0700 Subject: [ppml] 256/3 was Re: 240/4 In-Reply-To: References: Message-ID: Alain, > Alain Durand Wrote: > In the spirit of "let's write an RFC to free up some > space and the problem will go away", I would like to > suggest to write an RFC opening up 256/3. I think this is a great idea. Plus, we wouldn't even have to touch the core routing system: all we need is a little patch of the NAT box IPv4 stack to compress the first 33 bits into 32 (STAC, maybe) and we're done. Michel. From dlw+arin at tellme.com Fri May 4 12:48:26 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 4 May 2007 09:48:26 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: References: <463253DC.4010609@bogomips.com> Message-ID: <20070504164826.GW22657@shell01.corp.tellme.com> On Thu, May 03, 2007 at 05:48:09PM -0400, Jason Schiller wrote: > Yes what we are talking about here is the amount of RIB and FIB memory > consumed. In short there are a limited number of routing slots, and IPv6 > prefixes take up more memory than IPv4 prefixes. Routing table bloat is a > big concern. It is a concern in IPv4, it is a concern in IPv6, and it is > a concern in a dual stack environment. Quick question - if we could somehow fix the routing problem, would you be in favor of the now abandoned proposal? I agree that the routing problem is serious and a major concern for any proposal that allows, frankly, any space to be allocated. I think the concerns you've raised besides the routing table issues have been addressed by Owen, so I won't echo those thoughts. -David From info at arin.net Fri May 4 12:49:01 2007 From: info at arin.net (Member Services) Date: Fri, 04 May 2007 12:49:01 -0400 Subject: [ppml] ARIN XIX Meeting Report Now Available Message-ID: <463B63FD.20204@arin.net> The ARIN community recently concluded the ARIN XIX Public Policy and Members Meetings, held in San Juan, Puerto Rico, 22-25 April 2007. The meeting report includes presentations, summary notes, and transcripts of these meetings, and is now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XIX/ In addition to these files, the page referenced will have links added to an archive of the meeting's webcast next week. We thank all in the community who participated either in person or remotely, and look forward to seeing you all again for ARIN XX in Albuquerque, New Mexico, 17-19 October 2007. Regards, Member Services American Registry for Internet Numbers (ARIN) From alh-ietf at tndh.net Fri May 4 17:04:23 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 4 May 2007 14:04:23 -0700 Subject: [ppml] 240/4 In-Reply-To: References: <010b01c78da8$8b11a500$a134ef00$@net> Message-ID: <021d01c78e8f$cadff190$609fd4b0$@net> michael.dillon wrote: > ... > > Windows software is regularly patched, more often than server software > in my experience. I am not concerned about any specific behaviour in > Windows because I know that once the 240/4 RFC goes out, MS will be > motivated to fix them. Again it is not about MSFT fixing current code it is about getting it deployed. Just because patches are offered does not mean they get installed. > > > It is not a matter of fixing the code, it is about the reality of > getting > > the old systems weeded out of deployment. > > That is an issue for the organizations that decide they want to try > using the newly available 240/4 space. I am not going to try and second > guess their motives or how they might deploy the space. Networks are not > as homogenous as you imagine. The RFC that releases 240/4 is not > directed at Joe Sixpack which is why the RIRs will be instructed to warn > applicants an get them to state that they are aware of the technical > problems with 240/4. So you will be the first to sign up for a large block of 240/4, then convince a VC to invest heavily in server infrastructure to offer the next YouTube? What will you tell the investors when it turns out that Joe-sixpack can't even get to that space? PING: transmit failed, error code 1231 Error 1231: "The remote network is not reachable by the transport" (ERROR_NETWORK_UNREACHABLE). Note this is a very different error than an unreachable unicast address: Pinging 1.1.1.1 with 32 bytes of data: Request timed out. > > > but it should be made clear that use of that space has to be for a > > completely self-contained collection of new end systems with no > > expectation > > of it every working to interact with the rest of the IPv4 address > space > > (including 1918). > > The RFC should not say that the 240/4 space MUST be used for a > self-contained deployment, but it SHOULD warn that this MAY be the only > useful way of using such addresses. If there is any implication that the space is useful for interacting with the non-240/4 space, the author should be personally liable to the VC that invests as described above. A clear health warning has to accompany any document that defines 240/4. Tony From bicknell at ufp.org Fri May 4 22:11:32 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 4 May 2007 22:11:32 -0400 Subject: [ppml] 240/4 In-Reply-To: <84942.1178288152@sa.vix.com> References: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> <20070504130620.GA28372@ussenterprise.ufp.org> <84942.1178288152@sa.vix.com> Message-ID: <20070505021132.GA61988@ussenterprise.ufp.org> In a message written on Fri, May 04, 2007 at 02:15:52PM +0000, vixie at vix.com wrote: > > *** /usr/src/sys/netinet/in.h.orig Fri May 4 08:58:10 2007 > > --- /usr/src/sys/netinet/in.h Fri May 4 08:58:38 2007 > > *************** > > *** 341,349 **** > > - #define IN_EXPERIMENTAL(i) (((u_int32_t)(i) & 0xf0000000) == 0xf0000000) > > - #define IN_BADCLASS(i) (((u_int32_t)(i) & 0xf0000000) == 0xf0000000) > > you can't remove these macros. just make them always-return-zero. I realized after the fact that making these return 0 always is probably a better (short term?) solution. Although grep showed that FreeBSD's /kernel/ didn't use them anywhere else, user land utilities and third party programs may use those macros. Making them return 0 will "fix" all of those problems with a simple recompile. Perhaps best of both worlds, is return 0 with a compile time warning pointing to the new RFC. So yes, the vendors need to get the appropriate developers in the room, decide on an approach, and fix the code. However, the code fix should be trivial for this one. Least you mistake the vendors hesitation, let me also explain their real motivation. Deploying IPv6: 1) On "newish" hardware, it's simply a code upgrade. Generally covered under existing support contracts, with no incremental revenue. 2) On "old" hardware, IPv6 isn't useful, as you loose hardware acceleration if it can run v6 code at all. This means you buy a new router, the vendor gets incremental hardware revenue. Deploying the IPv4 Patch: 1) On all hardware, ship a new image. Generally covered under existing support contracts with no incremental revenue. Plus, given there will be a time when both old and new code is in production, they will have to take support calls (also no incremental revenue) on people doing dumb things that don't work. Even though this is a one or two line change for the vendor, and the cost to write the patch is as close to zero as they get, there are costs to support it with zero offset in incremental revenue. With IPv6, the costs are higher, but they are offset with incremental revenue which also has the nice side effect to deploying newer hardware that's easier to support, and enables upsale to other services. There's lots of incremental revenue to go after. And that's the real story why the vendors want you to believe this is "hard". -- 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 vixie at vix.com Fri May 4 22:26:18 2007 From: vixie at vix.com (vixie at vix.com) Date: Sat, 05 May 2007 02:26:18 +0000 Subject: [ppml] 240/4 In-Reply-To: Your message of "Fri, 04 May 2007 22:11:32 -0400." <20070505021132.GA61988@ussenterprise.ufp.org> References: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> <20070504130620.GA28372@ussenterprise.ufp.org> <84942.1178288152@sa.vix.com> <20070505021132.GA61988@ussenterprise.ufp.org> Message-ID: <74583.1178331978@sa.vix.com> > Even though this is a one or two line change for the vendor, and > the cost to write the patch is as close to zero as they get, there > are costs to support it with zero offset in incremental revenue. we know from botnet hunting that hundreds of thousands of win9x PC's are never patched, and that in spite of their incredible infection levels, are still used every day by people who buy stuff. what this means in practice is that no matter how easy the patch might be to produce and distribute, there will not be sufficient uptake that anyone large enough to need space from 240/4 would ever(*) be willing to deploy it as "public unicast". by "ever" i mean that the heat death of the universe would be more likely to occur first, or else, the wide scale usefulness of "public ipv6 unicast" would occur first. so, 240/4 as an extension of RFC1918 space makes sense to me. large ISP's can't do enough private addressing with the space RFC1918 reserves, and so, on the assumption that it'll be used for internal infrastructure where the deployer will be in better control of the software revision level, that's what i think ought to be done with it. From kloch at kl.net Fri May 4 23:53:39 2007 From: kloch at kl.net (Kevin Loch) Date: Fri, 04 May 2007 23:53:39 -0400 Subject: [ppml] 240/4 In-Reply-To: <74583.1178331978@sa.vix.com> References: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> <20070504130620.GA28372@ussenterprise.ufp.org> <84942.1178288152@sa.vix.com> <20070505021132.GA61988@ussenterprise.ufp.org> <74583.1178331978@sa.vix.com> Message-ID: <463BFFC3.4030208@kl.net> vixie at vix.com wrote: > we know from botnet hunting that hundreds of thousands of win9x PC's are never > patched, and that in spite of their incredible infection levels, are still > used every day by people who buy stuff. what this means in practice is that > no matter how easy the patch might be to produce and distribute, there will > not be sufficient uptake that anyone large enough to need space from 240/4 > would ever(*) be willing to deploy it as "public unicast". by "ever" i mean > that the heat death of the universe would be more likely to occur first, or > else, the wide scale usefulness of "public ipv6 unicast" would occur first. I consider the requirement that anything using 240/4 would be patched up to at least 2007 levels a significant feature :) > so, 240/4 as an extension of RFC1918 space makes sense to me. large ISP's > can't do enough private addressing with the space RFC1918 reserves, and so, > on the assumption that it'll be used for internal infrastructure where the > deployer will be in better control of the software revision level, that's > what i think ought to be done with it. How much of the /4 would we need for rfc1918 type space? Would a /6 be enough? It might be wise to save the rest of it for future, as yet unimagined use. I wonder if any of the various encapsulation approaches to id/locator split could make use of some of that space. - Kevin From vixie at vix.com Sat May 5 00:55:45 2007 From: vixie at vix.com (vixie at vix.com) Date: Sat, 05 May 2007 04:55:45 +0000 Subject: [ppml] 240/4 In-Reply-To: Your message of "Fri, 04 May 2007 23:53:39 -0400." <463BFFC3.4030208@kl.net> References: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> <20070504130620.GA28372@ussenterprise.ufp.org> <84942.1178288152@sa.vix.com> <20070505021132.GA61988@ussenterprise.ufp.org> <74583.1178331978@sa.vix.com> <463BFFC3.4030208@kl.net> Message-ID: <90705.1178340945@sa.vix.com> > How much of the /4 would we need for rfc1918 type space? Would a /6 be > enough? i don't think so. the folks who find 10/8 inadequate want a LOT LOT LOT more, not just a little more. > It might be wise to save the rest of it for future, as yet unimagined use. > I wonder if any of the various encapsulation approaches to id/locator split > could make use of some of that space. there is no future for IPv4 nor any reason to reserve or experiment. we're just looking for some fumes to breathe while we finally take IPv6 seriously. From tme at multicasttech.com Sat May 5 09:00:25 2007 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 5 May 2007 09:00:25 -0400 Subject: [ppml] 240/4 In-Reply-To: <90705.1178340945@sa.vix.com> References: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> <20070504130620.GA28372@ussenterprise.ufp.org> <84942.1178288152@sa.vix.com> <20070505021132.GA61988@ussenterprise.ufp.org> <74583.1178331978@sa.vix.com> <463BFFC3.4030208@kl.net> <90705.1178340945@sa.vix.com> Message-ID: <0BABC529-AD5F-4BF4-B96B-7AAC2F99267A@multicasttech.com> On May 5, 2007, at 12:55 AM, vixie at vix.com wrote: >> How much of the /4 would we need for rfc1918 type space? Would a / >> 6 be >> enough? > > i don't think so. the folks who find 10/8 inadequate want a LOT > LOT LOT > more, not just a little more. In that case, why don't they adopt v6 and be done with it ? Regards Marshall > >> It might be wise to save the rest of it for future, as yet >> unimagined use. >> I wonder if any of the various encapsulation approaches to id/ >> locator split >> could make use of some of that space. > > there is no future for IPv4 nor any reason to reserve or > experiment. we're > just looking for some fumes to breathe while we finally take IPv6 > seriously. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From jordi.palet at consulintel.es Sat May 5 09:16:25 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 05 May 2007 15:16:25 +0200 Subject: [ppml] 240/4 In-Reply-To: <0BABC529-AD5F-4BF4-B96B-7AAC2F99267A@multicasttech.com> Message-ID: Hi Marshall, That's what they are doing, for example DOCSIS 2.0 -> 3.0 in cable. True that they should have started to thing on this much earlier and go faster for it, but "better late than never" :-) Regards, Jordi > De: Marshall Eubanks > Responder a: > Fecha: Sat, 5 May 2007 09:00:25 -0400 > Para: > CC: 'Public Policy Mailing List' > Asunto: Re: [ppml] 240/4 > > > On May 5, 2007, at 12:55 AM, vixie at vix.com wrote: > >>> How much of the /4 would we need for rfc1918 type space? Would a / >>> 6 be >>> enough? >> >> i don't think so. the folks who find 10/8 inadequate want a LOT >> LOT LOT >> more, not just a little more. > > In that case, why don't they adopt v6 and be done with it ? > > Regards > Marshall > >> >>> It might be wise to save the rest of it for future, as yet >>> unimagined use. >>> I wonder if any of the various encapsulation approaches to id/ >>> locator split >>> could make use of some of that space. >> >> there is no future for IPv4 nor any reason to reserve or >> experiment. we're >> just looking for some fumes to breathe while we finally take IPv6 >> seriously. >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From rhw2 at rhwsun.wooten.net Sat May 5 09:47:52 2007 From: rhw2 at rhwsun.wooten.net (Richard Wooten) Date: Sat, 05 May 2007 09:47:52 -0400 Subject: [ppml] 240/4 In-Reply-To: <0BABC529-AD5F-4BF4-B96B-7AAC2F99267A@multicasttech.com> References: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> <20070504130620.GA28372@ussenterprise.ufp.org> <84942.1178288152@sa.vix.com> <20070505021132.GA61988@ussenterprise.ufp.org> <74583.1178331978@sa.vix.com> <463BFFC3.4030208@kl.net> <90705.1178340945@sa.vix.com> <0BABC529-AD5F-4BF4-B96B-7AAC2F99267A@multicasttech.com> Message-ID: <463C8B08.1030304@rhwsun.wooten.net> Please guys, your beating a dead horse. There needs to be a date set for the move to IPv6 and be done with it, do I like it, no, but it is the correct move to make. Best Regards, Richard Marshall Eubanks wrote: >On May 5, 2007, at 12:55 AM, vixie at vix.com wrote: > > > >>>How much of the /4 would we need for rfc1918 type space? Would a / >>>6 be >>>enough? >>> >>> >>i don't think so. the folks who find 10/8 inadequate want a LOT >>LOT LOT >>more, not just a little more. >> >> > >In that case, why don't they adopt v6 and be done with it ? > >Regards >Marshall > > > >>>It might be wise to save the rest of it for future, as yet >>>unimagined use. >>>I wonder if any of the various encapsulation approaches to id/ >>>locator split >>>could make use of some of that space. >>> >>> >>there is no future for IPv4 nor any reason to reserve or >>experiment. we're >>just looking for some fumes to breathe while we finally take IPv6 >>seriously. >>_______________________________________________ >>This message sent to you through the ARIN Public Policy Mailing List >>(PPML at arin.net). >>Manage your mailing list subscription at: >>http://lists.arin.net/mailman/listinfo/ppml >> >> > >_______________________________________________ >This message sent to you through the ARIN Public Policy Mailing List >(PPML at arin.net). >Manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at vix.com Sat May 5 11:54:39 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 05 May 2007 15:54:39 +0000 Subject: [ppml] 240/4 In-Reply-To: Your message of "Sat, 05 May 2007 09:00:25 -0400." <0BABC529-AD5F-4BF4-B96B-7AAC2F99267A@multicasttech.com> References: <85F2ED12-47D2-4D2D-A8F0-8828B5606520@nosignal.org> <00ff01c78cfa$84cb5820$8e620860$@net> <07131311-B75B-4224-8EF6-8AD06690FB54@nosignal.org> <010101c78da5$c3c5d130$4b517390$@net> <20070503173734.GA3124@nosignal.org> <20070504014449.GA11286@vacation.karoshi.com.> <20070504130620.GA28372@ussenterprise.ufp.org> <84942.1178288152@sa.vix.com> <20070505021132.GA61988@ussenterprise.ufp.org> <74583.1178331978@sa.vix.com> <463BFFC3.4030208@kl.net> <90705.1178340945@sa.vix.com> <0BABC529-AD5F-4BF4-B96B-7AAC2F99267A@multicasttech.com> Message-ID: <54591.1178380479@sa.vix.com> > > i don't think so. the folks who find 10/8 inadequate want a LOT LOT LOT > > more, not just a little more. > > In that case, why don't they adopt v6 and be done with it ? do we want to be prescriptive in that way, or responsive? if someone wants to build a big private ipv4 network and can hack their devices to run 240/4 and that space is otherwise useless, should we say "no, use ipv6 instead"? From Yves.Poppe at vsnlinternational.com Sun May 6 13:43:47 2007 From: Yves.Poppe at vsnlinternational.com (Yves Poppe) Date: Sun, 6 May 2007 13:43:47 -0400 Subject: [ppml] 240/4 In-Reply-To: <463C8B08.1030304@rhwsun.wooten.net> Message-ID: Richard is absolutely correct, let's move on. This is also what I just tried to reflect in my little column for the month of May for the Go6 website. see http://www.go6.net/4105/news-details.asp?news_id=593 I very much like Paul Vixie's earlier comment : "there is no future for IPv4 nor any reason to reserve or experiment. we're just looking for some fumes to breathe while we finally take IPv6 seriously" Yves Poppe -----Message d'origine----- De : ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]De la part de Richard Wooten Envoy? : Saturday, May 05, 2007 9:48 AM ? : Marshall Eubanks Cc : ppml at arin.net Objet : Re: [ppml] 240/4 Please guys, your beating a dead horse. There needs to be a date set for the move to IPv6 and be done with it, do I like it, no, but it is the correct move to make. Best Regards, Richard Marshall Eubanks wrote: On May 5, 2007, at 12:55 AM, vixie at vix.com wrote: How much of the /4 would we need for rfc1918 type space? Would a / 6 be enough? i don't think so. the folks who find 10/8 inadequate want a LOT LOT LOT more, not just a little more. In that case, why don't they adopt v6 and be done with it ? Regards Marshall It might be wise to save the rest of it for future, as yet unimagined use. I wonder if any of the various encapsulation approaches to id/ locator split could make use of some of that space. there is no future for IPv4 nor any reason to reserve or experiment. we're just looking for some fumes to breathe while we finally take IPv6 seriously. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List ( PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List ( PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at sprunk.org Mon May 7 08:49:11 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 7 May 2007 07:49:11 -0500 Subject: [ppml] Revised Policy Proposal Resource Reclamation References: <20070501124504.GA17437@ussenterprise.ufp.org><01d501c78c30$ffc6b580$4a3816ac@atlanta.polycom.com> Message-ID: <000a01c790a6$2ecbfd80$6501a8c0@atlanta.polycom.com> Thus spake >> Unfortunately, helping people and developing tools are not >> policy matters. > > I strongly disagree on that point. I certainly don't want to see > policy which goes into too much detail on such things, but I think > that it is entirely appropriate for ARIN policy to specify broadly > what type of educational activities ARIN should engage in, as > well as what sort of tools it should develop. For instance, I > supported the broad thrust of the PGP policy which directed > ARIN to build tools so that communications with ARIN could be > authenticated with PGP. And I changed my position on those three proposals for the same reason. Education, communication, tools, etc. are not "number resource policy". Those things belong to the ACSP. However, you're definitely welcome to float policy proposals in this direction and see what the AC and BoT say. > The fact is that ARIN policy has never had much detail on what > constitutes justification for an IP address block. There is a bit > more detail in RFC 2050 but nowhere is there an explanation > of what documentation is sufficient to show "justification" or > what records must be kept. I agree that's a problem. This proposal doesn't make the situation any worse than it is today. If you're unhappy with the status quo and think ARIN staff is abusing the lack of guidelines around "justification", that is definitely within the realm of policy. That nobody has done so in ten years tells me it's not that pressing a problem. >> Except in cases where ARIN has cause to suspect fraud, they >> would trust that you're not lying (much), just as they do today. I >> avoided using the term "audit" because that implies having to >> prove your records are correct (e.g. to the IRS). > > Audit is a general accounting term totally unrelated to the IRS. It > refers to the process of crosschecking records looking for > inconsistencies that would indicate someone is falsifying data or > siphoning off money etc. It is a perfectly valid term to use in a policy > which asks ARIN to check a company's records to make sure that > JUSTIFICATION for an address block continues to exist. Reviewing someone's records (with the assumption they're correct) to see if justification still exists and still meets current policy is an entirely different thing than auditing their records to see if they're correct. If you cannot see that distinction and the motivation behind it, we'll have to agree to disagree and spare everyone else the bickering. >> org has to produce records sufficient for ARIN to complete the >> review, and if they don't have them, they need to generate them. > > This is what I object to. I strongly object to ARIN contacting me and > demanding that I show justification, not just for 6 months supply of > addresses, but 15 years or so. As it stands, ARIN does not believe it has jurisdiction over anything issued prior to its formation, so 15 years ago is misleading. Also, current policy _already_ requires you to pass a review of _all_ your existing space before you can get more. If you, as an ISP, are not prepared to go through that process every six months when you go back for new space, you're already in trouble. This policy doesn't really do anything new to ISPs; it really only affects end-user orgs who currently _never_ have to rejustify space after they get it -- and that's where most of the waste (and low-hanging fruit) is. > I would object less to a policy which defines the records that I > must keep on hand, and mentions, in one clause, that ARIN can > request me to submit these defined records at any time. Hint: The RSA requires you to submit anything ARIN wants at any time. This proposal is an _improvement_ since it limits how often ARIN can do that to you, what your options are if they're not happy, and how much of a grace period you get. You're welcome to create separate proposal on what records constitute "justification", which would be a complementary limit. >> The proposed grace period gives them time to renumber. > > The grace period is not stated as a time for the org to renumber > but as a waiting period for ARIN before reissuing the addresses. > Why isn't it 12 months like in 4.6 Amnesty requests. I'd be happy with 12 or even 24 months; in fact one staffer has already suggested that to me privately. If that were the only thing stopping people from supporting the proposal, either Owen and I could revise it or the AC could adjust the number during last call. Also, the proposal specifically says that ARIN will work with any reasonable request for a longer duration. > Why isn't it tied to the last allocation period, i.e. did they ask for > a 3 or 6 month supply? Because that 3/6 month supply must have been a minimum of 12 mos ago; if the org hasn't managed to get reasonably close to the requirements that allocation was issued under, another few mos won't help. Also, not all resources issued are allocations, and not all allocations are tied to a 3/6 month window. By leaving it to "compliant with current policy", a huge variety of situations can be handled. Not everyone is an ISP. > There is a similar situation with the LIRs customers. When a > customer moves to another ISP, they are supposed to return and > renumber. Not only does 4.2.3.3 not specify 6 months, it doesn't > mention any specific time period. Why doesn't this proposal fix > that? Also, the customer does not have to return the block until > after the renumbering period, but the proposal asks ARIN to pull > back the block from the LIR first, before the renumbering period. No, it says that return or revocation is immediate for _billing_ purposes. That doesn't mean it doesn't show up in WHOIS or isn't officially connected to the org during the renumbering period, just that they don't have to pay for it since it's going away. > These kinds of flaws show that very little thought went into this > proposal an almost no effort was made to make it fit into the > set of existing policies. These kinds of proposals don't make > any sense and I can't figure out what the point is of submitting > them, other than to waste our time. Just because you fear something doesn't mean it's nonsensical or a waste of time. > This is a proposal to make a MAJOR change to ARIN practice. I suggest you go read your RSA before you say that again. > Such a proposal should not even be submitted before it is > vetted in detail by several people. By "in detail" I mean that they > suggest a lot of changes and adjustments that show they did > more than spend 5 minutes scanning the proposal. It was. Just because those several people don't agree with you doesn't mean their time and effort was a waste. Don't worry; you have six months until the next meeting to try to convince others that the idea is flawed, offer a counter-proposal, or politely suggest changes that address your issues with the current one. >> > ... I believe that ARIN's role here has to be in helping an org >> > reach compliance, not in punishing an org or pulling the rug out >> > from under them. >> >> ARIN cannot help an org reach compliance. ARIN could, >> however, help them prove they were in compliance. There's >> a serious difference there. > > If ARIN would use the education hat to deal with this issue, then > they could indeed help an org reach compliance. I'm not asking > them to send out free consultants to spend a week in your office. Either an org's resources are justified under current policy or they aren't. There is absolutely nothing ARIN can do to change that. Education might help people learn how to demonstrate their compliance, or avoid asking for things they won't be able to justify, or notify people about significant policy changes that could lead to resources no longer being justified. Tools would help standardize data formats and reduce the cost (to both sides) of a review. Education, of course, would also teach people how to use the tools. >> ARIN has policy on what justifies an allocation/assignment. It >> has changed slowly over time, but not so much that someone >> still assuming rules from five years ago is likely to be in >> trouble today. > > Where is it defined so clearly that ARIN can be confident they > will not be sued if they claim that an org no longer "justifies" their > allocation? The policy does not have to be written in a way that > attracts lawsuits. If counsel thinks there's a problem, we'll fix it or withdraw it. Owen and I both respect Mr. Ryan and will make whatever changes we need to to address his concerns. >> I think it's best to get people (including staff!) used to the idea >> of reviews, what documentation they'll need, etc. now while >> they're still highly likely to pass. > > So you believe that it is OK to provide documentation and > education to staff Of course it's okay for a company to educate its employees. > but not OK to do the same for ARIN members? Something is > wrong here. What's wrong is you're deliberately misreading things. I said several times that I'm all for education, and even the quote you were responding to was directed at members and the comment about staff was only parenthetical. >> The charter requires stewardship. We would be irresponsible >> stewards if we did not verify the need of people consuming a >> limited resource that others _can_ justify a need for. > > IP addresses are virtually unlimited. IPv4 may be running low, > but there is a vast supply of IPv6 addresses now available. If you really think that IPv4 and IPv6 addresses are interchangeable, I've got a bridge in Brooklyn to sell you. > Here again, ARIN is failing its charter because it is not taking > its education role seriously. Check the PPML archives. I asked the BoT to do more outreach about IPv6 and the response was it was against the charter. Don't waste your time yelling at the people who are on your side. > This is fantasy. The reason audit processes exist is because > of a whole range of human issues which lead to bitrot. ARIN > may trust me but do they trust my data sources within the > organization and all the many people who monkey with that > data? Currently they do, unless they have reason to suspect fraud. Again, that's why I termed it a "review" instead of an "audit". ARIN staff know that everyone fibs a little when trying to justify a request, plus some percentage of that justification being subject to bit rot. Neither of those realities stop people from getting new space, nor would they stop them from passing a review under the same circumstances a year or three later. In fact, it's the looseness of the term "justify" that requires ARIN to err on the side of the member in practice. Defining what exactly it means may hurt more than it helps, depending on your perspective. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From kkargel at polartel.com Mon May 7 10:35:45 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 7 May 2007 09:35:45 -0500 Subject: [ppml] 240/4 In-Reply-To: <54591.1178380479@sa.vix.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706ED1@mail> Getting my 2 pence in... I may not say it as eloquently or precisely as the rest of you have done, but please bear with me. If we try to make a change by placing arbitrary enforcable rules we are going about this entirely the wrong way. To make laws you need not only to be a recognized governing body, but you also need a police force with the time, manpower, energy and money to enforce your rules. We need to remember that none of the groups writing IP policies (not laws) is a government. ARIN is a registry, ICANN is a corporation, IANA is a subdivision of ICANN.. The only reason any of these organizations function (and they do it very well, don't get me wrong) is the cooperation of the internet 'community' at large. Cooperative anarchy was the principle that let the internet function at the onset, and that is still the best way of doing it today. If we arrange things so that IPv6 is easier to use, works better and is cheaper than IPv4 then people will flock to it as fast as assimilation is possible. If we try to force people to IPv6 through punitive measures people will grab hold of IPv4 so hard you will never pry them away from it. If we want that internet 'community' to stand on their heads in the corner then the way to get them to do that is to arrange services so that it is easier, cheaper and more functional to do it your way that any other. People will do what is easier first, then what is cheaper. People will rarely do what you tell them just because you say "they have to". If we try to force change on folks by making rules, they will ignore the rules as long as possible. If we try to make it more expensive to ignore the new rules by artificially inflating costs then people will just find another way around and ignore us altogether. In the words of John Taylor Gatto.. "... genius is as common as dirt. We suppress our genius only because we haven't yet figured out how to manage a population of educated men and women. The solution, I think, is simple and glorious. Let them manage themselves." > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Paul Vixie > Sent: Saturday, May 05, 2007 10:55 AM > To: 'Public Policy Mailing List' > Subject: Re: [ppml] 240/4 > > > > i don't think so. the folks who find 10/8 inadequate > want a LOT LOT > > > LOT more, not just a little more. > > > > In that case, why don't they adopt v6 and be done with it ? > > do we want to be prescriptive in that way, or responsive? if > someone wants to build a big private ipv4 network and can > hack their devices to run 240/4 and that space is otherwise > useless, should we say "no, use ipv6 instead"? > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From michael.dillon at bt.com Mon May 7 12:36:04 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 7 May 2007 17:36:04 +0100 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: <000a01c790a6$2ecbfd80$6501a8c0@atlanta.polycom.com> References: <20070501124504.GA17437@ussenterprise.ufp.org><01d501c78c30$ffc6b580$4a3816ac@atlanta.polycom.com> <000a01c790a6$2ecbfd80$6501a8c0@atlanta.polycom.com> Message-ID: > > The fact is that ARIN policy has never had much detail on what > > constitutes justification for an IP address block. There is a bit > > more detail in RFC 2050 but nowhere is there an explanation > > of what documentation is sufficient to show "justification" or > > what records must be kept. > > I agree that's a problem. This proposal doesn't make the situation any > worse than it is today. If you're unhappy with the status quo and think > ARIN staff is abusing the lack of guidelines around "justification", that > is > definitely within the realm of policy. That nobody has done so in ten > years > tells me it's not that pressing a problem. Don't put words in my mouth. I'm not suggesting that staff are abusing anything. However, I am suggesting that the authors of the policy proposal are abusing the situation. Making policy more punitive in regards to "justification" is entirely inappropriate without first improving the clarity around what constitutes justification. > Reviewing someone's records (with the assumption they're correct) to see > if > justification still exists and still meets current policy is an entirely > different thing than auditing their records to see if they're correct. If > you cannot see that distinction and the motivation behind it, we'll have > to > agree to disagree and spare everyone else the bickering. Since the policy gives ARIN the power to seize back number resources, I don't think it is appropriate to do that on the basis of an informal review. I see that the author has removed the word "audit" in favour of "review", but I still have an issue with any punitive action being made on such an informal basis. > As it stands, ARIN does not believe it has jurisdiction over anything > issued > prior to its formation, so 15 years ago is misleading. That is not what ARIN counsel's comments at the last ARIN meeting suggest. If you believe this to be the case then why does your policy language not include this limitation? > Also, current policy _already_ requires you to pass a review of _all_ your > existing space before you can get more. If you, as an ISP, are not > prepared > to go through that process every six months when you go back for new > space, > you're already in trouble. If you really want your policy to refer to exactly the same review process as for additional allocations, then why doesn't the policy state this in plain English. Nevertheless, since this policy asks ARIN to take punitive actions, I think it needs to first clean up vaguenesses in existing policy and practice. Otherwise someone can get an allocation and a year later be facing punitive action even though they have done nothing wrong. > This policy doesn't really do anything new to > ISPs; it really only affects end-user orgs who currently _never_ have to > rejustify space after they get it -- and that's where most of the waste > (and > low-hanging fruit) is. If this policy is directed at end-users, then why does it start with the phrase "resources allocated or assigned to an organization."? > Hint: The RSA requires you to submit anything ARIN wants at any time. > This > proposal is an _improvement_ since it limits how often ARIN can do that to > you, what your options are if they're not happy, and how much of a grace > period you get. The RSA does not specify punitive actions that ARIN will take. > You're welcome to create separate proposal on what records constitute > "justification", which would be a complementary limit. You're NOT welcome to propose policies which give ARIN policing powers and allow ARIN to impose punitive measures until AFTER you fix the policy on which you base your proposal. > Because that 3/6 month supply must have been a minimum of 12 mos ago; if > the > org hasn't managed to get reasonably close to the requirements that > allocation was issued under, another few mos won't help. In this message you have finally stated some of the assumptions on which this proposal was based. I don't understand why you didn't do this at the outset. Here you seem to be saying that addresses should flow back and forth between ARIN and orgs periodically, not just when business improves. This seems to be a rather more bureaucratic model of RIR like RIPE. I'm not sure that this is the right direction to be headed. > > This is a proposal to make a MAJOR change to ARIN practice. > > I suggest you go read your RSA before you say that again. Contract terms and ARIN practices are different things. > Education might help people learn how to demonstrate their compliance, or > avoid asking for things they won't be able to justify, or notify people > about significant policy changes that could lead to resources no longer > being justified. Tools would help standardize data formats and reduce the > cost (to both sides) of a review. Education, of course, would also teach > people how to use the tools. Bingo! All of these are things that ARIN can and should do better. Policy can be used to enable some aspects of this. Official suggestions can deal with some other aspects. > What's wrong is you're deliberately misreading things. I said several > times > that I'm all for education, and even the quote you were responding to was > directed at members and the comment about staff was only parenthetical. Then why do you want to take punitive measure in an area where education could resolve the problem. And if the education activity doesn't work, it lays the groundwork for punitive measures that would stand up in the courts. > > IP addresses are virtually unlimited. IPv4 may be running low, > > but there is a vast supply of IPv6 addresses now available. > > If you really think that IPv4 and IPv6 addresses are interchangeable, I've > got a bridge in Brooklyn to sell you. >From the point of view of applications, IPv4 and IPv6 are indeed interchangeable. From the point of view of network topology, they are also interchangeable. It isn't necessary for every org to switch new consumption to IPv6 addresses in order to remove the pressures on IPv4 address space. > > This is fantasy. The reason audit processes exist is because > > of a whole range of human issues which lead to bitrot. ARIN > > may trust me but do they trust my data sources within the > > organization and all the many people who monkey with that > > data? > > Currently they do, unless they have reason to suspect fraud. Again, > that's > why I termed it a "review" instead of an "audit". We need to get this IRS and fraud issue out of the discussion. The words used in ARIN's policies will be interpreted by ordinary business people and therefore, ARIN should use the meaning commonly accepted in the business world. The word "audit" does not imply fraud. It is a common business term referring to a systematic review of data to verify its accuracy. The word "audit" implies that there is a certain systematic process, and a certain thoroughness to the review. It also implies that the review goes according to some sort of plan which is considered best practice in the business discipline (accounting, quality control, etc.). There is a business dictionary that I found via Google which defines it here: http://www.businessdictionary.com/definition/audit.html > ARIN staff know that everyone fibs a little when trying to justify a > request, plus some percentage of that justification being subject to bit > rot. Neither of those realities stop people from getting new space, nor > would they stop them from passing a review under the same circumstances a > year or three later. In fact, it's the looseness of the term "justify" > that > requires ARIN to err on the side of the member in practice. Defining what > exactly it means may hurt more than it helps, depending on your > perspective. It's the looseness of this whole process that leads me to object to using this as the basis for punitive action. I don't object to auditing, per se, but because of the looseness, today and in the past, I don't think that the audit should lead to any punitive measures. --Michael Dillon From owen at delong.com Mon May 7 13:02:34 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 7 May 2007 10:02:34 -0700 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: <20070501124504.GA17437@ussenterprise.ufp.org><01d501c78c30$ffc6b580$4a3816ac@atlanta.polycom.com> <000a01c790a6$2ecbfd80$6501a8c0@atlanta.polycom.com> Message-ID: > >> This policy doesn't really do anything new to >> ISPs; it really only affects end-user orgs who currently _never_ have > to >> rejustify space after they get it -- and that's where most of the > waste >> (and >> low-hanging fruit) is. > > If this policy is directed at end-users, then why does it start > with the > phrase "resources allocated or assigned to an organization."? > Perhaps, Mr. Dillon, you are unclear on ARIN terminology in this area. ARIN issues resources only to organizations. Those organizations are divided into two categories for purposes of ARIN policy. "Subscriber" organizations (also termed variously LIR and ISP in various parts of ARIN policy) receive allocations eligible for subsequent reassignment and/or reallocation to other entities, and "End User" organizations (also termed "Direct Assignments" in ARIN policy). In all cases, it refers to resources issued to organizations because it is clear in ARIN policy that resources are issued to organizations and not individuals. >> Hint: The RSA requires you to submit anything ARIN wants at any time. >> This >> proposal is an _improvement_ since it limits how often ARIN can do > that to >> you, what your options are if they're not happy, and how much of a > grace >> period you get. > > The RSA does not specify punitive actions that ARIN will take. > The RSA does specify that ARIN may discontinue the registration of your resources to you. I do not see how this differs from what you are referring to as punitive action in our proposal. >> You're welcome to create separate proposal on what records constitute >> "justification", which would be a complementary limit. > > You're NOT welcome to propose policies which give ARIN policing powers > and allow ARIN to impose punitive measures until AFTER you fix the > policy on which you base your proposal. > It is our belief that this proposal simply clarifies existing policy in this area and provides a more direct representation of what is already codified in the NRPM and the RSA. In fact, we believe this proposal places a greater burden on ARIN for process prior to revocation, AND, more limitations on the speed with which resources can be revoked. > >>> This is a proposal to make a MAJOR change to ARIN practice. >> >> I suggest you go read your RSA before you say that again. > > Contract terms and ARIN practices are different things. > Contract terms and policies are not. The contract and policies should be consistent with each other. Practice should, at least on some level, be consistent with both. > > Bingo! > All of these are things that ARIN can and should do better. Policy can > be used to enable some aspects of this. Official suggestions can deal > with some other aspects. > Fantastic... Propose something. That's not the issue we're trying to address here, so, such effort is orthogonal to discussion of this policy proposal. >> What's wrong is you're deliberately misreading things. I said >> several >> times >> that I'm all for education, and even the quote you were responding to > was >> directed at members and the comment about staff was only > parenthetical. > > Then why do you want to take punitive measure in an area where > education > could resolve the problem. And if the education activity doesn't work, > it lays the groundwork for punitive measures that would stand up in > the > courts. > First of all, I take issue with your use of the term punitive. ARIN has a responsibility of stewardship over community resources and issues those resources to organizations in the community based on justified need. Reclamation of resources which no longer have justified need is not punitive, it is good stewardship. >>> IP addresses are virtually unlimited. IPv4 may be running low, >>> but there is a vast supply of IPv6 addresses now available. >> >> If you really think that IPv4 and IPv6 addresses are interchangeable, > I've >> got a bridge in Brooklyn to sell you. > >> From the point of view of applications, IPv4 and IPv6 are indeed > interchangeable. From the point of view of network topology, they are > also interchangeable. It isn't necessary for every org to switch new > consumption to IPv6 addresses in order to remove the pressures on IPv4 > address space. > Actually, that depends a great deal on the application. To the best of my knowledge, there are no applications where a v6 only client can open a socket directly to a v4 only server without some intervening translation process. Hence, any claim of interchangeability is specious at best. > > We need to get this IRS and fraud issue out of the discussion. The > words > used in ARIN's policies will be interpreted by ordinary business > people > and therefore, ARIN should use the meaning commonly accepted in the > business world. The word "audit" does not imply fraud. It is a common > business term referring to a systematic review of data to verify its > accuracy. The word "audit" implies that there is a certain systematic > process, and a certain thoroughness to the review. It also implies > that > the review goes according to some sort of plan which is considered > best > practice in the business discipline (accounting, quality control, > etc.). > There is a business dictionary that I found via Google which > defines it > here: > http://www.businessdictionary.com/definition/audit.html > I could care less whether we term it an audit or a review. Either way, there is emotion surrounding the terms on one side or another. Personally, I think review is the less emotionally charged term, but, in any case, it is a review of the justification and documentation supporting the justification of a resource allocation that is intended here. >> ARIN staff know that everyone fibs a little when trying to justify a >> request, plus some percentage of that justification being subject to > bit >> rot. Neither of those realities stop people from getting new space, > nor >> would they stop them from passing a review under the same > circumstances a >> year or three later. In fact, it's the looseness of the term > "justify" >> that >> requires ARIN to err on the side of the member in practice. Defining > what >> exactly it means may hurt more than it helps, depending on your >> perspective. > > It's the looseness of this whole process that leads me to object to > using this as the basis for punitive action. I don't object to > auditing, > per se, but because of the looseness, today and in the past, I don't > think that the audit should lead to any punitive measures. > Then we are agreed. Since what is proposed is not a punitive measure, merely the reclamation of a resource if the utilization is no longer justified, I am glad to see you will be supporting the policy after all. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From michael.dillon at bt.com Mon May 7 13:30:22 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 7 May 2007 18:30:22 +0100 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: <20070501124504.GA17437@ussenterprise.ufp.org><01d501c78c30$ffc6b580$4a3816ac@atlanta.polycom.com> <000a01c790a6$2ecbfd80$6501a8c0@atlanta.polycom.com> Message-ID: > First of all, I take issue with your use of the term punitive. ARIN > has a > responsibility of stewardship over community resources and issues > those resources to organizations in the community based on justified > need. Reclamation of resources which no longer have justified need > is not punitive, it is good stewardship. Your proposal talks about revocation of resources. It discusses the terms under which ARIN may unilaterally change the status of number resources which had previously been delegated to another organization. I believe that a court would see that as punitive action and that if ARIN were ever sued as a result of such action, ARIN would have to "justify" that punitive action to the court. Regardless of whether or not it is good stewardship to reclaim resources whose delegation is no longer justified, the actions describe in your proposal are punitive actions. > Actually, that depends a great deal on the application. To the best > of my > knowledge, there are no applications where a v6 only client can open a > socket directly to a v4 only server without some intervening translation > process. Hence, any claim of interchangeability is specious at best. I wasn't talking about the network, I was talking about the application. An application that functions on a v4 network (say a web client talking to a web server) will function on a v6 network without any changes to the application. If ARIN takes a stewardship attitude to IP address resources overall, then it is wrong to be overly strict with IPv4 addresses unless there is some level of education about the availability and interchangeability of IPv6 addresses. Given the timeframes for IPv4 exhaustion, 3 to 5 years, there is plenty of time for enterprises and network operators to make IPv6 operational for many network functions. Any time that an application is shifted to IPv6, that eases the pressure on IPv4 and, ultimately we may be able to prevent IPv4 exhaustion by such measures. --Michael Dillon From stephen at sprunk.org Mon May 7 14:17:00 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 7 May 2007 13:17:00 -0500 Subject: [ppml] Revised Policy Proposal Resource Reclamation References: <20070501124504.GA17437@ussenterprise.ufp.org><01d501c78c30$ffc6b580$4a3816ac@atlanta.polycom.com><000a01c790a6$2ecbfd80$6501a8c0@atlanta.polycom.com> Message-ID: <012201c790d4$00aa5d60$6501a8c0@atlanta.polycom.com> Thus spake >> As it stands, ARIN does not believe it has jurisdiction over >> anything issued prior to its formation, so 15 years ago is >> misleading. > > That is not what ARIN counsel's comments at the last ARIN > meeting suggest. I watched the meeting video, I've reviewed the transcript to clarify things, and I've been told about other conversations people have had on the topic. What I got out of all that is that Mr. Ryan feels that we can deny service to legacy holders but we _probably_ can't take space back from one who fights us. He said that it's "an interesting theory" to claim escheat applies to abandoned number resources but hadn't had much time to think about it. > If you believe this to be the case then why does your policy > language not include this limitation? Because we found it counter-productive to preclude a proposal which might change that stance. This proposal, therefore, intentionally does not address the issue either way. Absent any other policy action that passes muster with counsel, ARIN will continue to consider legacy space untouchable as it does today. >> Also, current policy _already_ requires you to pass a review >> of _all_ your existing space before you can get more. If you, >> as an ISP, are not prepared to go through that process every >> six months when you go back for new space, you're already >> in trouble. > > If you really want your policy to refer to exactly the same review > process as for additional allocations, then why doesn't the > policy state this in plain English. I thought that was self-evident by making a "without cause" review a parallel item with a "new request" review. Absent language that indicates intent to make the result different, a reasonable person assumes that the intent was to make the result the same. > Nevertheless, since this policy asks ARIN to take punitive > actions, I think it needs to first clean up vaguenesses in existing > policy and practice. Otherwise someone can get an allocation > and a year later be facing punitive action even though they > have done nothing wrong. If they've done nothing wrong, how do you propose they'll be "substantially not in compliance with current policy"? The only way that should ever occur is if policy changed so significantly in the meantime that their original request would not have been approved (or even reasonably close to it). However, a policy change that significant, such as I expect to see when we get close to exhaustion, would have to be made with the express intent of affecting past allocations and assignments or it'd be pointless. >> This policy doesn't really do anything new to ISPs; it really >> only affects end-user orgs who currently _never_ have to >> rejustify space after they get it -- and that's where most of the >> waste (and low-hanging fruit) is. > > If this policy is directed at end-users, then why does it start with the > phrase "resources allocated or assigned to an organization."? Because it was an attempt to get all reviews, regardless of reason or org type, all in one place in the NRPM and under a consistent standard/process. The existing text (see the sections to be deleted) is arguably worse than the new text as far as your arguments go, and it's not consistent with the RSA. > Here you seem to be saying that addresses should flow back > and forth between ARIN and orgs periodically, not just when > business improves. This seems to be a rather more > bureaucratic model of RIR like RIPE. I'm not sure that this is > the right direction to be headed. If the org has shrunk, or got way too much space to begin with (i.e. they'll never grow into it), they should give some back. I doubt you disagree with either of those cases. If the org is growing slower than expected, but will still grow into what they got within a reasonable timeframe, it would be a waste of time and effort to take back resources from them and reissue them later unless we're at the end game where the only way to get resources for new, properly justified applications is to take back older, unjustified resources. That world will be ugly no matter what we do. >> > This is fantasy. The reason audit processes exist is because >> > of a whole range of human issues which lead to bitrot. ARIN >> > may trust me but do they trust my data sources within the >> > organization and all the many people who monkey with that >> > data? >> >> Currently they do, unless they have reason to suspect fraud. >> Again, that's why I termed it a "review" instead of an "audit". > > We need to get this IRS and fraud issue out of the discussion. > The words used in ARIN's policies will be interpreted by ordinary > business people and therefore, ARIN should use the meaning > commonly accepted in the business world. Right; I know the word "audit" has a commonly-accepted meaning and, since I didn't want to imply that meaning, I didn't use that word in the revised proposal text (though I missed editing it out of the rationale). You are the one who keeps harping on it, not me. > The word "audit" does not imply fraud. It is a common business > term referring to a systematic review of data to verify its accuracy. If ARIN has a reason to suspect fraud, they will audit records. Absent suspicion of fraud, they will simply review your records and assume they're correct, i.e. that review will _not_ be an audit. Neither of those cases is a change from current practice. WRT the sections I didn't quote, I think Owen's response is sufficient. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From schiller at uu.net Mon May 7 18:44:42 2007 From: schiller at uu.net (Jason Schiller) Date: Mon, 07 May 2007 18:44:42 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070504164826.GW22657@shell01.corp.tellme.com> Message-ID: ---------- Forwarded message ---------- On Fri, 4 May 2007, David Williamson wrote: > Quick question - if we could somehow fix the routing problem, would you > be in favor of the now abandoned proposal? I agree that the routing > problem is serious and a major concern for any proposal that allows, > frankly, any space to be allocated. First off I don't think I would be in favor of the now abandoned proposal. As you point out there are a few issues (such as the spammers using and black-lising lots of space) that need to be addressed. I suspect these have been addressed (or shortly will be). However I still have some concerns about their adequacy, but maybe that is just details. > I think the concerns you've raised besides the routing table issues > have been addressed by Owen, so I won't echo those thoughts. I may have missed one of Owen's posts, but allowing ARIN to reclaim addresses used illegitimately isn't enough. I do admint, that taking back resources from orgizations that stop being multi-homed would probably be enough of a deterrent to prevent them for being multi-home for just a year to get a PI block. However, we need to prevent spammers from getting lots of address space black-listted in the first place. Once they are black listed, it will be difficult to clean, and likely make the reclaimed address space unusable. This is why I suggested maybe if an orgization is multi-homed for 6 months, they should qualify. This would likely deter spammers as they would need to keep their accounts in order for 180 days. This would also deter many orgization who simply want PI addresses and have no intention of actually multi-homing. Ideally, I would like the policy to say anyone who is multi-homed prior to Aug 2007 can qualify for PI /24s, but no new multi-homers will qualify. This is the only way the policy could be crafted to not create more routes in the table, but of course that is not a balanced and fair policy. As for the routing table size challenge, well, that depends on what exactly you mean by "fix", but assuming the following: 1. I have no worries about my routers running out of RIB/FIB memory. 2. I have no worries about slow path selection 3. I have no worries about slow RIB to FIB population 4. I have no worries about slow boot time convergence 5. I have no worries about CPU utilization in handeling updates 6. I have no worries about doing FIB lookup at line rate w/ small packets 7. I have no worries that I will need to upgrade my routers just to keep up with routing table growth (routers should last at least 5 years) 8. I have no worries that routers will be cost prohibitive 9. I have no worries that routers will be too large, or be too heavy 10. I have no worries that routers will run too hot or require too much cooling or electricity (did I miss anything?) Then yes, if the consuming extra address space, and the consuming extra routing slots issues are adquately addressed then I suppose I would vote in favor of this policy. Personally I suspect any "fix" that addresses the routing table size challenge will be a new architecture where multi-homing, TE, and PI are all accomplished without the need to route more specifics, or carry lots of state. Thus it is likely such an architectural approach would also eliminate the need for PI addresses. __Jason From sor at stjohns.edu Mon May 7 18:51:39 2007 From: sor at stjohns.edu (Roger So) Date: Mon, 7 May 2007 18:51:39 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned Message-ID: <1C461639E23A4549979E2F4EBB88E6C60B0010@SQNEWMAIL.admin.ads.stjohns.edu> How many ports ? ----- Original Message ----- From: ppml-bounces at arin.net To: David Williamson Cc: ppml at arin.net ; Jason Schiller Sent: Mon May 07 18:44:42 2007 Subject: Re: [ppml] Policy Proposal 2007-6 - Abandoned ---------- Forwarded message ---------- On Fri, 4 May 2007, David Williamson wrote: > Quick question - if we could somehow fix the routing problem, would you > be in favor of the now abandoned proposal? I agree that the routing > problem is serious and a major concern for any proposal that allows, > frankly, any space to be allocated. First off I don't think I would be in favor of the now abandoned proposal. As you point out there are a few issues (such as the spammers using and black-lising lots of space) that need to be addressed. I suspect these have been addressed (or shortly will be). However I still have some concerns about their adequacy, but maybe that is just details. > I think the concerns you've raised besides the routing table issues > have been addressed by Owen, so I won't echo those thoughts. I may have missed one of Owen's posts, but allowing ARIN to reclaim addresses used illegitimately isn't enough. I do admint, that taking back resources from orgizations that stop being multi-homed would probably be enough of a deterrent to prevent them for being multi-home for just a year to get a PI block. However, we need to prevent spammers from getting lots of address space black-listted in the first place. Once they are black listed, it will be difficult to clean, and likely make the reclaimed address space unusable. This is why I suggested maybe if an orgization is multi-homed for 6 months, they should qualify. This would likely deter spammers as they would need to keep their accounts in order for 180 days. This would also deter many orgization who simply want PI addresses and have no intention of actually multi-homing. Ideally, I would like the policy to say anyone who is multi-homed prior to Aug 2007 can qualify for PI /24s, but no new multi-homers will qualify. This is the only way the policy could be crafted to not create more routes in the table, but of course that is not a balanced and fair policy. As for the routing table size challenge, well, that depends on what exactly you mean by "fix", but assuming the following: 1. I have no worries about my routers running out of RIB/FIB memory. 2. I have no worries about slow path selection 3. I have no worries about slow RIB to FIB population 4. I have no worries about slow boot time convergence 5. I have no worries about CPU utilization in handeling updates 6. I have no worries about doing FIB lookup at line rate w/ small packets 7. I have no worries that I will need to upgrade my routers just to keep up with routing table growth (routers should last at least 5 years) 8. I have no worries that routers will be cost prohibitive 9. I have no worries that routers will be too large, or be too heavy 10. I have no worries that routers will run too hot or require too much cooling or electricity (did I miss anything?) Then yes, if the consuming extra address space, and the consuming extra routing slots issues are adquately addressed then I suppose I would vote in favor of this policy. Personally I suspect any "fix" that addresses the routing table size challenge will be a new architecture where multi-homing, TE, and PI are all accomplished without the need to route more specifics, or carry lots of state. Thus it is likely such an architectural approach would also eliminate the need for PI addresses. __Jason _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From vixie at vix.com Thu May 10 14:58:50 2007 From: vixie at vix.com (vixie at vix.com) Date: Thu, 10 May 2007 18:58:50 +0000 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) Message-ID: <97549.1178823530@sa.vix.com> i think that this article will help inform the debate around the ipv6 transition: http://arstechnica.com/articles/paedia/ipv6-firewall-mixed-blessing.ars From alh-ietf at tndh.net Fri May 11 00:01:02 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 11 May 2007 07:01:02 +0300 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <97549.1178823530@sa.vix.com> References: <97549.1178823530@sa.vix.com> Message-ID: <013401c79381$003efa20$00bcee60$@net> I agree that this will help inform the debate, and while Iljitsch did a good job of outlining the issue, he left out a significant point::: People explicitly chose to be in the state of "as there is currently no obvious way to make services only available locally" by insisting that the local-scope addressing range have a global-scope as far as application developers were concerned. Now the application developers are complaining about the consequences of their choice, because the alternative to 'no routing path for an attack' is to insert a device that has to make policy decisions with limited information. The current ULA-central discussions will be directly involved in this issue. It is critical that all of the RIR's have policies establishing a mechanism for registering ULA-central prefixes & PI. For those who don't recall, the reason ULA-central was tabled was that it was seen as a potential end-run to acquire PI space in the absence of appropriate policy to do so out of a range recognized for global routing. The need for keeping some things local while others are global is real, and the lack of appropriate mechanisms to accomplish that through the routing system that is designed to deal with path selection leads to entire industries for fragile work-arounds along with their increased complexity. Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > vixie at vix.com > Sent: Thursday, May 10, 2007 9:59 PM > To: ppml at arin.net > Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica > (seen on slashdot) > > i think that this article will help inform the debate around the ipv6 > transition: > > http://arstechnica.com/articles/paedia/ipv6-firewall-mixed-blessing.ars > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From william at elan.net Fri May 11 03:03:08 2007 From: william at elan.net (william(at)elan.net) Date: Fri, 11 May 2007 00:03:08 -0700 (PDT) Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <013401c79381$003efa20$00bcee60$@net> References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy. On Fri, 11 May 2007, Tony Hain wrote: > I agree that this will help inform the debate, and while Iljitsch did a good > job of outlining the issue, he left out a significant point::: > People explicitly chose to be in the state of "as there is currently no > obvious way to make services only available locally" by insisting that the > local-scope addressing range have a global-scope as far as application > developers were concerned. Now the application developers are complaining > about the consequences of their choice, because the alternative to 'no > routing path for an attack' is to insert a device that has to make policy > decisions with limited information. > > The current ULA-central discussions will be directly involved in this issue. > It is critical that all of the RIR's have policies establishing a mechanism > for registering ULA-central prefixes & PI. For those who don't recall, the > reason ULA-central was tabled was that it was seen as a potential end-run to > acquire PI space in the absence of appropriate policy to do so out of a > range recognized for global routing. > > The need for keeping some things local while others are global is real, and > the lack of appropriate mechanisms to accomplish that through the routing > system that is designed to deal with path selection leads to entire > industries for fragile work-arounds along with their increased complexity. > > Tony > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> vixie at vix.com >> Sent: Thursday, May 10, 2007 9:59 PM >> To: ppml at arin.net >> Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica >> (seen on slashdot) >> >> i think that this article will help inform the debate around the ipv6 >> transition: >> >> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed-blessing.ars >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Fri May 11 02:12:21 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 10 May 2007 23:12:21 -0700 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: ULA Central is intended so that some subset of the internet can reliably use it to interconnect while not being "globally" routed. The problem I have with this theory is that the delta between a collection of networks routing by mutual agreement and the internet is: A. Fuzzy B. Non-Existant C. There is no difference D. Meaningless E. Any and/or All of the above Pick your favorite answer from the above and you've pretty much got it. If ULA central were limited to not exiting the local AS (in some meaningful way, like routers won't forward routes or traffic to ULA addresses to external adjacencies), then, I might see it as something other than an end-run on the RIR process. However, in it's current state of "license for anyone who wants to run a competing RIR for networks that choose to interoperate on this basis" I think it's a pretty bad idea. Owen On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: > > I don't understand your point about why ULA need to be registered if > its not going to be globally routed. Also PI is not the same as ULA - > PI do come from RIRs and in IPv6 there was no way to get PI (except > in a few special cases) until recent ARIN's micro-allocation policy. > > On Fri, 11 May 2007, Tony Hain wrote: > >> I agree that this will help inform the debate, and while Iljitsch >> did a good >> job of outlining the issue, he left out a significant point::: >> People explicitly chose to be in the state of "as there is >> currently no >> obvious way to make services only available locally" by insisting >> that the >> local-scope addressing range have a global-scope as far as >> application >> developers were concerned. Now the application developers are >> complaining >> about the consequences of their choice, because the alternative to >> 'no >> routing path for an attack' is to insert a device that has to make >> policy >> decisions with limited information. >> >> The current ULA-central discussions will be directly involved in >> this issue. >> It is critical that all of the RIR's have policies establishing a >> mechanism >> for registering ULA-central prefixes & PI. For those who don't >> recall, the >> reason ULA-central was tabled was that it was seen as a potential >> end-run to >> acquire PI space in the absence of appropriate policy to do so out >> of a >> range recognized for global routing. >> >> The need for keeping some things local while others are global is >> real, and >> the lack of appropriate mechanisms to accomplish that through the >> routing >> system that is designed to deal with path selection leads to entire >> industries for fragile work-arounds along with their increased >> complexity. >> >> Tony >> >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>> Behalf Of >>> vixie at vix.com >>> Sent: Thursday, May 10, 2007 9:59 PM >>> To: ppml at arin.net >>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in >>> arstechnica >>> (seen on slashdot) >>> >>> i think that this article will help inform the debate around the >>> ipv6 >>> transition: >>> >>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- >>> blessing.ars >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From michael.dillon at bt.com Fri May 11 03:28:54 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 11 May 2007 08:28:54 +0100 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: > I don't understand your point about why ULA need to be registered if > its not going to be globally routed. Also PI is not the same as ULA - > PI do come from RIRs and in IPv6 there was no way to get PI (except > in a few special cases) until recent ARIN's micro-allocation policy. ULA addresses *WILL* be globally routed on an IPv6 internetwork. It just won't be the IP internetwork known as the Internet. Remember, IP addresses are not for use on the Internet, they are for use on IP networks. --Michael Dillon From michael.dillon at bt.com Fri May 11 03:41:10 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 11 May 2007 08:41:10 +0100 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica(seen on slashdot) In-Reply-To: References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: > The problem I have with this theory is that the delta between a > collection > of networks routing by mutual agreement and the internet is: > > A. Fuzzy > B. Non-Existant > C. There is no difference > D. Meaningless > E. Any and/or All of the above > > Pick your favorite answer from the above and you've pretty much got it. Perhaps it is time for the RIRs to develop clear definitions for the Internet and IP internetworks so that the delta between them is clear. > However, in it's current state of "license for > anyone who > wants to run a competing RIR for networks that choose to interoperate > on this basis" I think it's a pretty bad idea. The RIR process is the way that the organizations sharing IP number resources reach agreement on who gets what. These organizations have to work together outside of the RIRs to reach agreement on who connects to what and who routes what. If a group of organizations outside the RIR can reach agreement on global internetwork connectivity between them, but separate from the Internet, and if the IP number resource pool is big enough to let these organizations manage their own addressing requirements on that internetwork, then why should the RIRs be upset. Among the many IP networks operated by my company there is a global IPv4 internetwork that is completely separate from the Internet. It has thousands of companies connected to it and, naturally, it uses registered IPv4 addresses. It's not the only such global network. We run one for the financial services industry. There is also such a network for the auto-manufacturing industry, and for the airline industry. And there are probably others as well. --Michael Dillon From info at arin.net Fri May 11 04:14:31 2007 From: info at arin.net (Member Services) Date: Fri, 11 May 2007 04:14:31 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing Message-ID: <464425E7.1070305@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next regularly scheduled meeting. If their meeting is within ten days, then the review may be extended to the subsequent meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 Soft Landing Author: David Conrad Proposal Version: 1.0 Submission Date: 2007-05-02 Proposal type: New Policy term: Permanent Policy statement: 30 days after specified thresholds in the amount of address space remaining in the IANA IPv4 free pool are crossed, the requirements necessary for ISPs to obtain additional IPv4 address space are made more stringent and requesters must demonstrate efforts both to utilize scarce IPv4 address space more efficiently, set up IPv6 infrastructure services, and eventually offer production IPv6 connectivity. The proposed thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are: Phase 0 Threshold N/A Requirements Requesters must demonstrate: * No requirements to document IPv6 infrastructure services or IPv6 connectivity services. * 80% utilization in all customer assignments as reflected in SWIP/rwhois reassignments * Downstream immediate requirement: 25% * Downstream requirement after 1 year: 50% Phase 1 Threshold 40 /8s Requirements: Requesters must demonstrate: * Documented plans for availability of production IPv6 infrastructure services within 6 months * Documented plans for availability of production IPv6 service within 1 year * 85% utilization in all customer assignments as reflected in SWIP/rwhois reassignments * Downstream immediate requirement: 33% * Downstream requirement after 1 year: 66% Phase 2 Threshold 30 /8s Requirements: Requesters must demonstrate: * Documented availability of production IPv6 infrastructure services * Documented plans for availability of production IPv6 service within 6 months * 90% utilization in all customer assignments as reflected in SWIP/rwhois reassignments * Current 3rd-party auditors report of IPv4 address space utilization * Downstream immediate requirement: 50% * Downstream requirement after 1 year: 75% Phase 3 Threshold 20 /8s Requirements: Requesters must demonstrate: * Documented availability of production IPv6 infrastructure services * Documented availability of production IPv6 connectivity service * A migration plan for all internal infrastructure to either IPv6 or private addressing * 92% utilization in all customer assignments as reflected in SWIP/rwhois reassignments * Current 3rd-party auditors report of IPv4 address space utilization * Downstream immediate requirement: 60% * Downstream requirement after 1 year: 80% Phase 4 Threshold 15 /8s Requirements: Requesters must demonstrate: * Documented availability of production IPv6 connectivity services * Initiation of migration of internal infrastructure to either IPv6 or private addressing * 94% utilization in all customer assignments as reflected in SWIP/rwhois reassignments * Current 3rd-party auditors report of IPv4 address space utilization * Downstream immediate requirement: 70% * Downstream requirement after 1 year: 85% Internal infrastructure can be used in justification for IPv4 address space only in special circumstances Phase 5 Threshold 10 /8s Requirements: Requesters must demonstrate: * Documented availability of production IPv6 connectivity services * Recycling of 25% of (non-private) IPv4 address space formerly used for internal infrastructure * 96% utilization in all customer assignments as reflected in SWIP/rwhois reassignments * Current 3rd-party auditors report of IPv4 address space utilization * Downstream immediate requirement: 75% * Downstream requirement after 1 year: 90% Internal infrastructure can no longer be used in justification for IPv4 address space Phase 6 Threshold 5 /8s Requirements: Requesters must demonstrate: * Documented availability of production IPv6 connectivity services * Recycling of 75% of IPv4 address space formerly used for internal infrastructure * 98% utilization in all customer assignments as reflected in SWIP/rwhois reassignments * Current 3rd-party auditors report of IPv4 address space utilization * Downstream immediate requirement: 80% * Downstream requirement after 1 year: 95% Internal infrastructure can no longer be used in justification for IPv4 address space Note that for the purposes of this proposal, the following definitions apply: * Downstream: entities to which the ISP may assign address space. * IPv6 infrastructure services: services such as DNS, WWW, FTP, etc. accessible via IPv6. * IPv6 connectivity: IP connectivity service provided over IPv6 transport, either natively or via an IPv6 tunnel. * Internal infrastructure: routers, switches, servers, etc., that are not normally visible or directly accessed by the ISP customers. Phase 0 reflects current allocation requirements. Subsequent phases of this policy are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space. Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses to requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by making the allocation of IPv4 both more difficult and contingent on the ISP demonstrating both support for IPv6 as well as more efficient use of the IPv4 address space they administer. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the reuse of IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify utilization of customer requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby breaking the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. The requirement to provide a current third-party auditors report of utilization is intended to deter fraudulent justification data used to support IPv4 allocations in the absence of actual need. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. This policy anticipates ARIN staff will make use of auditor reports to verify appropriate use of IPv4 addresses in internal infrastructure. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when their current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. From jordi.palet at consulintel.es Fri May 11 04:37:36 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 11:37:36 +0300 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Message-ID: Even if not globally routed, you may want to avoid a possible clash with another organization, for example in case of a merge. ULA-central is NOT intended to be uses as IPv6 PI. IPv6 PI is available already in ARIN, APNIC and AfriNIC. Ongoing policy proposals in both RIPE NCC and LACNIC. Regards, Jordi (I'm the the one that submitted the ULA-central policy proposal to all the regions, ARIN coming next) > De: "william(at)elan.net" > Responder a: > Fecha: Fri, 11 May 2007 00:03:08 -0700 (PDT) > Para: Tony Hain > CC: , , "address-policy-wg at ripe.net" > > Asunto: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen > on slashdot) > > > I don't understand your point about why ULA need to be registered if > its not going to be globally routed. Also PI is not the same as ULA - > PI do come from RIRs and in IPv6 there was no way to get PI (except > in a few special cases) until recent ARIN's micro-allocation policy. > > On Fri, 11 May 2007, Tony Hain wrote: > >> I agree that this will help inform the debate, and while Iljitsch did a good >> job of outlining the issue, he left out a significant point::: >> People explicitly chose to be in the state of "as there is currently no >> obvious way to make services only available locally" by insisting that the >> local-scope addressing range have a global-scope as far as application >> developers were concerned. Now the application developers are complaining >> about the consequences of their choice, because the alternative to 'no >> routing path for an attack' is to insert a device that has to make policy >> decisions with limited information. >> >> The current ULA-central discussions will be directly involved in this issue. >> It is critical that all of the RIR's have policies establishing a mechanism >> for registering ULA-central prefixes & PI. For those who don't recall, the >> reason ULA-central was tabled was that it was seen as a potential end-run to >> acquire PI space in the absence of appropriate policy to do so out of a >> range recognized for global routing. >> >> The need for keeping some things local while others are global is real, and >> the lack of appropriate mechanisms to accomplish that through the routing >> system that is designed to deal with path selection leads to entire >> industries for fragile work-arounds along with their increased complexity. >> >> Tony >> >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >>> vixie at vix.com >>> Sent: Thursday, May 10, 2007 9:59 PM >>> To: ppml at arin.net >>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica >>> (seen on slashdot) >>> >>> i think that this article will help inform the debate around the ipv6 >>> transition: >>> >>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed-blessing.ars >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri May 11 04:54:10 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 11:54:10 +0300 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Message-ID: If we want to avoid other entities acting as a central registry for ULA-central, then it is clear that the RIRs should do that, and for that, the only way is thru a policy. Regards, Jordi > De: Owen DeLong > Responder a: > Fecha: Thu, 10 May 2007 23:12:21 -0700 > Para: "william(at)elan.net" > CC: Tony Hain , , , > "address-policy-wg at ripe.net" > Asunto: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT > in arstechnica (seen on slashdot) > > ULA Central is intended so that some subset of the internet can reliably > use it to interconnect while not being "globally" routed. > > The problem I have with this theory is that the delta between a > collection > of networks routing by mutual agreement and the internet is: > > A. Fuzzy > B. Non-Existant > C. There is no difference > D. Meaningless > E. Any and/or All of the above > > Pick your favorite answer from the above and you've pretty much got it. > If ULA central were limited to not exiting the local AS (in some > meaningful > way, like routers won't forward routes or traffic to ULA addresses to > external > adjacencies), then, I might see it as something other than an end-run on > the RIR process. However, in it's current state of "license for > anyone who > wants to run a competing RIR for networks that choose to interoperate > on this basis" I think it's a pretty bad idea. > > Owen > > > On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: > >> >> I don't understand your point about why ULA need to be registered if >> its not going to be globally routed. Also PI is not the same as ULA - >> PI do come from RIRs and in IPv6 there was no way to get PI (except >> in a few special cases) until recent ARIN's micro-allocation policy. >> >> On Fri, 11 May 2007, Tony Hain wrote: >> >>> I agree that this will help inform the debate, and while Iljitsch >>> did a good >>> job of outlining the issue, he left out a significant point::: >>> People explicitly chose to be in the state of "as there is >>> currently no >>> obvious way to make services only available locally" by insisting >>> that the >>> local-scope addressing range have a global-scope as far as >>> application >>> developers were concerned. Now the application developers are >>> complaining >>> about the consequences of their choice, because the alternative to >>> 'no >>> routing path for an attack' is to insert a device that has to make >>> policy >>> decisions with limited information. >>> >>> The current ULA-central discussions will be directly involved in >>> this issue. >>> It is critical that all of the RIR's have policies establishing a >>> mechanism >>> for registering ULA-central prefixes & PI. For those who don't >>> recall, the >>> reason ULA-central was tabled was that it was seen as a potential >>> end-run to >>> acquire PI space in the absence of appropriate policy to do so out >>> of a >>> range recognized for global routing. >>> >>> The need for keeping some things local while others are global is >>> real, and >>> the lack of appropriate mechanisms to accomplish that through the >>> routing >>> system that is designed to deal with path selection leads to entire >>> industries for fragile work-arounds along with their increased >>> complexity. >>> >>> Tony >>> >>> >>>> -----Original Message----- >>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>> Behalf Of >>>> vixie at vix.com >>>> Sent: Thursday, May 10, 2007 9:59 PM >>>> To: ppml at arin.net >>>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in >>>> arstechnica >>>> (seen on slashdot) >>>> >>>> i think that this article will help inform the debate around the >>>> ipv6 >>>> transition: >>>> >>>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- >>>> blessing.ars >>>> _______________________________________________ >>>> This message sent to you through the ARIN Public Policy Mailing List >>>> (PPML at arin.net). >>>> Manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/ppml >>> >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From nali at forsythe.com Fri May 11 05:00:19 2007 From: nali at forsythe.com (Nadirshah N Ali) Date: Fri, 11 May 2007 04:00:19 -0500 Subject: [ppml] Nadirshah N Ali/Forsythe is out of the office. Message-ID: I will be out of the office starting 05/09/2007 and will not return until 05/15/2007. If this is an emergency, please contact Dan Rodgers. From michael.dillon at bt.com Fri May 11 08:05:04 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 11 May 2007 13:05:04 +0100 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464425E7.1070305@arin.net> References: <464425E7.1070305@arin.net> Message-ID: > Rationale: Where is the graphical timeline for this proposal? Where are the IPv4 runout charts with the phase points superimposed on them? Where is the table that explains this all in a more readable fashion than plain prose? I know that the policy must be written purely in prose, however the rationale can and should include other material when trying to explain something as complex as this proposal. Right now, I'd vote against this just because I don't know if I understand all the implications one way or the other. When in doubt, stick with the status quo. --Michael Dillon From alh-ietf at tndh.net Fri May 11 08:06:02 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 11 May 2007 14:06:02 +0200 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: <017601c793c4$c67c5aa0$53750fe0$@net> It is time to be blunt. The BS about being an end-run on PI is a tacit acknowledgement that people demand the utility of PI and will do whatever it takes to work around attempts to thwart them. The only reason ULA & PI are related is that there is no global acknowledgement that PI is necessary and will exist despite short-sighted attempts to squelch it. Also, just because someone else has a different deployment model off to the side that you don't see doesn't make it wrong. Enterprise networks need to keep private interconnect routing sorted out from their public side routing, and while complex IGP entries and ACLs will do the job, a simpler approach is to use the routing system for the job it was designed to do and use a local prefix for the non-global interconnect. PI does not solve the locality problem, so ULA is needed as well. For those organizations that don't want to consider even the remotest possibility that there will be an address collision with a future merger/acquisition/partner (having been burned on 1918), ULA-central makes more sense than ULA-local. Every PI block should automatically come with a ULA-central block. One could even argue that every RIR member should automatically receive a ULA-central block. Use is up to them. It has no ongoing cost so it would be cheaper to just set one up while doing the requested service than to have to come back and add it later. There is no shortage here. The RIR membership should really get past their preferred religion and start thinking long term revenue here. ULA-central doesn't cost anything substantial, yet provides a reason to justify RIR membership for those who don't consider ULA-local to be unique enough and would not otherwise become a member. Tony > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, May 11, 2007 9:12 AM > To: william(at)elan.net > Cc: Tony Hain; vixie at vix.com; ppml at arin.net; address-policy-wg at ripe.net > Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in > arstechnica (seen on slashdot) > > ULA Central is intended so that some subset of the internet can reliably > use it to interconnect while not being "globally" routed. > > The problem I have with this theory is that the delta between a > collection > of networks routing by mutual agreement and the internet is: > > A. Fuzzy > B. Non-Existant > C. There is no difference > D. Meaningless > E. Any and/or All of the above > > Pick your favorite answer from the above and you've pretty much got it. > If ULA central were limited to not exiting the local AS (in some > meaningful > way, like routers won't forward routes or traffic to ULA addresses to > external > adjacencies), then, I might see it as something other than an end-run on > the RIR process. However, in it's current state of "license for > anyone who > wants to run a competing RIR for networks that choose to interoperate > on this basis" I think it's a pretty bad idea. > > Owen > > > On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: > > > > > I don't understand your point about why ULA need to be registered if > > its not going to be globally routed. Also PI is not the same as ULA - > > PI do come from RIRs and in IPv6 there was no way to get PI (except > > in a few special cases) until recent ARIN's micro-allocation policy. > > > > On Fri, 11 May 2007, Tony Hain wrote: > > > >> I agree that this will help inform the debate, and while Iljitsch > >> did a good > >> job of outlining the issue, he left out a significant point::: > >> People explicitly chose to be in the state of "as there is > >> currently no > >> obvious way to make services only available locally" by insisting > >> that the > >> local-scope addressing range have a global-scope as far as > >> application > >> developers were concerned. Now the application developers are > >> complaining > >> about the consequences of their choice, because the alternative to > >> 'no > >> routing path for an attack' is to insert a device that has to make > >> policy > >> decisions with limited information. > >> > >> The current ULA-central discussions will be directly involved in > >> this issue. > >> It is critical that all of the RIR's have policies establishing a > >> mechanism > >> for registering ULA-central prefixes & PI. For those who don't > >> recall, the > >> reason ULA-central was tabled was that it was seen as a potential > >> end-run to > >> acquire PI space in the absence of appropriate policy to do so out > >> of a > >> range recognized for global routing. > >> > >> The need for keeping some things local while others are global is > >> real, and > >> the lack of appropriate mechanisms to accomplish that through the > >> routing > >> system that is designed to deal with path selection leads to entire > >> industries for fragile work-arounds along with their increased > >> complexity. > >> > >> Tony > >> > >> > >>> -----Original Message----- > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>> Behalf Of > >>> vixie at vix.com > >>> Sent: Thursday, May 10, 2007 9:59 PM > >>> To: ppml at arin.net > >>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in > >>> arstechnica > >>> (seen on slashdot) > >>> > >>> i think that this article will help inform the debate around the > >>> ipv6 > >>> transition: > >>> > >>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- > >>> blessing.ars > >>> _______________________________________________ > >>> This message sent to you through the ARIN Public Policy Mailing List > >>> (PPML at arin.net). > >>> Manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/ppml > >> > >> _______________________________________________ > >> This message sent to you through the ARIN Public Policy Mailing List > >> (PPML at arin.net). > >> Manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > This message sent to you through the ARIN Public Policy Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml From schiller at uu.net Fri May 11 09:05:10 2007 From: schiller at uu.net (Jason Schiller) Date: Fri, 11 May 2007 09:05:10 -0400 (EDT) Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Message-ID: Owen, I just want to be clear about somehting you said. You view ULA central as "an end-run on the RIR process." Is this because the expired ULC-central draft suggests that some new "central allocation authority" be established to assign these addresses? If the draft RFC was resurrected and all references to "cental allocation authority" and "cental authority" were removed and replaced with clear text explaining the following: - IANA should divide FC00::/8 into eight /11s - Each RIR would be given one /11 to make ULA-Central assignments - Three /11s would be held in reserve for new RIRs in the future. Would you still think this was an end-run on the RIR process? Would you be in support of the draft moving forward? Do you think this should not be decided by an RFC, but rather as a global policy through each of the RIRs? If you prefer the RIR process, would you be in favor of a global policy submitted to ARIN that had the provisions of the expired ULA-central draft, with the modification of removing "cental authority" and clearly designating how IANA should divide the space among the existing RIRs? ULA-central text snippets below. ___Jason draft-ietf-ipv6-ula-central-01.txt -- section 3.2.1 "Global IDs should be assigned under the authority of a single allocation organization because they are pseudo-random and without any structure. This is easiest to accomplish if there is a single authority for the assignments." draft-ietf-ipv6-ula-central-01.txt -- section 7.0 "The IANA is instructed to designate an allocation authority, based on instructions from the IAB, for centrally assigned Unique Local IPv6 unicast addresses. This allocation authority shall comply with the requirements described in Section 3.2 of this document, including in particular allocation on a permanent basis and with sufficient provisions to avoid hoarding of numbers. If deemed appropriate, the authority may also consist of multiple organizations performing the allocation authority duties. The designated allocation authority is required to document how they will meet the requirements described in Section 3.2 of this document in an RFC. This RFC will be shepherd through the IETF by the IAB." ========================================================================== 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, 10 May 2007, Owen DeLong wrote: > Date: Thu, 10 May 2007 23:12:21 -0700 > From: Owen DeLong > To: "william(at)elan.net" > Cc: vixie at vix.com, ppml at arin.net, address-policy-wg at ripe.net > Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica > (seen on slashdot) > > ULA Central is intended so that some subset of the internet can reliably > use it to interconnect while not being "globally" routed. > > The problem I have with this theory is that the delta between a > collection > of networks routing by mutual agreement and the internet is: > > A. Fuzzy > B. Non-Existant > C. There is no difference > D. Meaningless > E. Any and/or All of the above > > Pick your favorite answer from the above and you've pretty much got it. > If ULA central were limited to not exiting the local AS (in some > meaningful > way, like routers won't forward routes or traffic to ULA addresses to > external > adjacencies), then, I might see it as something other than an end-run on > the RIR process. However, in it's current state of "license for > anyone who > wants to run a competing RIR for networks that choose to interoperate > on this basis" I think it's a pretty bad idea. > > Owen > > > On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: > > > > > I don't understand your point about why ULA need to be registered if > > its not going to be globally routed. Also PI is not the same as ULA - > > PI do come from RIRs and in IPv6 there was no way to get PI (except > > in a few special cases) until recent ARIN's micro-allocation policy. > > > > On Fri, 11 May 2007, Tony Hain wrote: > > > >> I agree that this will help inform the debate, and while Iljitsch > >> did a good > >> job of outlining the issue, he left out a significant point::: > >> People explicitly chose to be in the state of "as there is > >> currently no > >> obvious way to make services only available locally" by insisting > >> that the > >> local-scope addressing range have a global-scope as far as > >> application > >> developers were concerned. Now the application developers are > >> complaining > >> about the consequences of their choice, because the alternative to > >> 'no > >> routing path for an attack' is to insert a device that has to make > >> policy > >> decisions with limited information. > >> > >> The current ULA-central discussions will be directly involved in > >> this issue. > >> It is critical that all of the RIR's have policies establishing a > >> mechanism > >> for registering ULA-central prefixes & PI. For those who don't > >> recall, the > >> reason ULA-central was tabled was that it was seen as a potential > >> end-run to > >> acquire PI space in the absence of appropriate policy to do so out > >> of a > >> range recognized for global routing. > >> > >> The need for keeping some things local while others are global is > >> real, and > >> the lack of appropriate mechanisms to accomplish that through the > >> routing > >> system that is designed to deal with path selection leads to entire > >> industries for fragile work-arounds along with their increased > >> complexity. > >> > >> Tony > >> > >> > >>> -----Original Message----- > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>> Behalf Of > >>> vixie at vix.com > >>> Sent: Thursday, May 10, 2007 9:59 PM > >>> To: ppml at arin.net > >>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in > >>> arstechnica > >>> (seen on slashdot) > >>> > >>> i think that this article will help inform the debate around the > >>> ipv6 > >>> transition: > >>> > >>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- > >>> blessing.ars > >>> _______________________________________________ > >>> This message sent to you through the ARIN Public Policy Mailing List > >>> (PPML at arin.net). > >>> Manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/ppml > >> > >> _______________________________________________ > >> This message sent to you through the ARIN Public Policy Mailing List > >> (PPML at arin.net). > >> Manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > This message sent to you through the ARIN Public Policy Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > From schiller at uu.net Fri May 11 09:14:36 2007 From: schiller at uu.net (Jason Schiller) Date: Fri, 11 May 2007 09:14:36 -0400 (EDT) Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Message-ID: On Fri, 11 May 2007, JORDI PALET MARTINEZ wrote: > Even if not globally routed, you may want to avoid a possible clash with > another organization, for example in case of a merge. > I agree. The importance of it being assigned by an authority is that that authority provides uniqueness. This is often important when an address collision occurs, such that one entity can prove they have the legitmate claim to use those numbers. Although these addresses may be used "internally" it is also important that they be capable to be supported by DNS (without setting up a split-horrizon DNS), for ease of management __Jason From michael.dillon at bt.com Fri May 11 09:35:25 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 11 May 2007 14:35:25 +0100 Subject: [ppml] Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: > If the draft RFC was resurrected > Would you still think this was an end-run on the RIR process? > > Would you be in support of the draft moving forward? Seems to me that if the draft is not resurrected, there are no ULA addresses for ARIN or RIPE to register, regardless of anything that ARIN or RIPE members might desire. > If you prefer the RIR process, would you be in favor of a global policy > submitted to ARIN that had the provisions of the expired ULA-central > draft, with the modification of removing "cental authority" and clearly > designating how IANA should divide the space among the existing RIRs? Seems to me that the NRO requires that identical policies be PASSED by all of the RIRs before they can be considered "global policy". This is an area where it makes a whole lot of sense to have discussions on several RIR mailing lists before ANY policy proposal is submitted to ANY of the 5 RIRs. I'm not going to quibble with the wording of the draft at this point. I just wonder whether it is appropriate for the RIR mailing lists to be used as a working group for writing Internet drafts? It seems to be a stupid way to proceed because there are at least 5 different mailing lists involved, one of which is primarily in Spanish. Crossposting is not a solution. If people are serious about this central ULA concept then they should get ONE of the RIRs to set up a working group (RIPE would be my first choice, ARIN second) and then have all of this discussion in that working group mailing list. People from all of the 5 RIRs should be invited to the working group by official RIR postings to whatever lists are appropriate. Some RIRs have announcement lists for such things or members-only lists to ensure that the word gets out. Then draft the document in your ONE SINGLE mailing list discussion, submit it to the IETF, and only then, after an agreed draft is formally in the IETF pipeline, submit your global policy proposals to each of the RIRs. The way this is being done right now is pure madness and I would expect that the RIR boards will reject any policies that arise through this UNFAIR AND DISJOINTED process. We have always allowed the IETF to take first place when it comes to creating new number resources. There is no good reason to change this for so-called central-ULA addresses. We do need the technical expertise that is in the IETF to review this before we can make any kind of policy decisions about a registry for these addresses. I know many people on the RIR policy lists are technical experts, but that doesn't count, because these are policy lists, not technical ones. It is one thing for a few technical people to convince a large number of non-technical people about a topic. It is another thing entirely, for those few technical people to convince the large number of technical people who participate in the IETF. It seems to me that the promoters of central-ULA are trying to bypass the IETF's technical review process and I don't like this. --Michael Dillon From owen at delong.com Fri May 11 09:38:39 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 11 May 2007 06:38:39 -0700 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: Message-ID: <90966F89-6CCB-44F5-8797-AD51317E0CC8@delong.com> On May 11, 2007, at 1:37 AM, JORDI PALET MARTINEZ wrote: > Even if not globally routed, you may want to avoid a possible clash > with > another organization, for example in case of a merge. > > ULA-central is NOT intended to be uses as IPv6 PI. > Intent is not the problem. Probability of implementation outside of the intent is the problem. ULA Central is only beneficial if it is somehow easier to get than IPv6 PI. If it is easier to get and there is no solid (router-enforced) way to preclude it from being "globally routed", then, it will get abused as an alternative to IPv6 PI. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Fri May 11 09:58:55 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 11 May 2007 06:58:55 -0700 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: Message-ID: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> On May 11, 2007, at 6:05 AM, Jason Schiller wrote: > Owen, > > I just want to be clear about somehting you said. You view ULA > central as > "an end-run on the RIR process." Is this because the expired ULC- > central > draft suggests that some new "central allocation authority" be > established > to assign these addresses? > > If the draft RFC was resurrected and all references to "cental > allocation > authority" and "cental authority" were removed and replaced with clear > text explaining the following: > > - IANA should divide FC00::/8 into eight /11s > - Each RIR would be given one /11 to make ULA-Central assignments > - Three /11s would be held in reserve for new RIRs in the future. > > Would you still think this was an end-run on the RIR process? > I would not think it was an end-run on RIRs at that point. > Would you be in support of the draft moving forward? > It would depend on what provisions were in the draft to prevent it from being an end-run on PI policies. > Do you think this should not be decided by an RFC, but rather as a > global > policy through each of the RIRs? > I am not sure. I kind of like Tony's (malformed) suggestion that ULA- C should come with PI. If the qualifications for ULA-C were the same, or, if ULA-C was only available to orgs. that had PI, I think that would be acceptable. > If you prefer the RIR process, would you be in favor of a global > policy > submitted to ARIN that had the provisions of the expired ULA-central > draft, with the modification of removing "cental authority" and > clearly > designating how IANA should divide the space among the existing RIRs? > Not sure about that. I do support the idea of ULA-Central as intended, but, I'd have to see a policy or RFC that implemented it in such a way that I had reasonable confidence it wouldn't become "the easy way to get PI". If we're going to do that, I'd rather do it by relaxing the PI policy than by designating some "nudge nudge wink wink" address space. Owen > ULA-central text snippets below. > > ___Jason > > > > draft-ietf-ipv6-ula-central-01.txt -- section 3.2.1 > "Global IDs should be assigned under the authority of a single > allocation organization because they are pseudo-random and without > any structure. This is easiest to accomplish if there is a single > authority for the assignments." > > draft-ietf-ipv6-ula-central-01.txt -- section 7.0 > > "The IANA is instructed to designate an allocation authority, > based on > instructions from the IAB, for centrally assigned Unique Local IPv6 > unicast addresses. This allocation authority shall comply with the > requirements described in Section 3.2 of this document, > including in > particular allocation on a permanent basis and with sufficient > provisions to avoid hoarding of numbers. If deemed appropriate, > the > authority may also consist of multiple organizations performing the > allocation authority duties. > > The designated allocation authority is required to document how > they > will meet the requirements described in Section 3.2 of this > document > in an RFC. This RFC will be shepherd through the IETF by the IAB." > > > > > > ====================================================================== > ==== > 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, 10 May 2007, Owen DeLong wrote: > >> Date: Thu, 10 May 2007 23:12:21 -0700 >> From: Owen DeLong >> To: "william(at)elan.net" >> Cc: vixie at vix.com, ppml at arin.net, address-policy-wg at ripe.net >> Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in >> arstechnica >> (seen on slashdot) >> >> ULA Central is intended so that some subset of the internet can >> reliably >> use it to interconnect while not being "globally" routed. >> >> The problem I have with this theory is that the delta between a >> collection >> of networks routing by mutual agreement and the internet is: >> >> A. Fuzzy >> B. Non-Existant >> C. There is no difference >> D. Meaningless >> E. Any and/or All of the above >> >> Pick your favorite answer from the above and you've pretty much >> got it. >> If ULA central were limited to not exiting the local AS (in some >> meaningful >> way, like routers won't forward routes or traffic to ULA addresses to >> external >> adjacencies), then, I might see it as something other than an end- >> run on >> the RIR process. However, in it's current state of "license for >> anyone who >> wants to run a competing RIR for networks that choose to interoperate >> on this basis" I think it's a pretty bad idea. >> >> Owen >> >> >> On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: >> >>> >>> I don't understand your point about why ULA need to be registered if >>> its not going to be globally routed. Also PI is not the same as >>> ULA - >>> PI do come from RIRs and in IPv6 there was no way to get PI (except >>> in a few special cases) until recent ARIN's micro-allocation policy. >>> >>> On Fri, 11 May 2007, Tony Hain wrote: >>> >>>> I agree that this will help inform the debate, and while Iljitsch >>>> did a good >>>> job of outlining the issue, he left out a significant point::: >>>> People explicitly chose to be in the state of "as there is >>>> currently no >>>> obvious way to make services only available locally" by insisting >>>> that the >>>> local-scope addressing range have a global-scope as far as >>>> application >>>> developers were concerned. Now the application developers are >>>> complaining >>>> about the consequences of their choice, because the alternative to >>>> 'no >>>> routing path for an attack' is to insert a device that has to make >>>> policy >>>> decisions with limited information. >>>> >>>> The current ULA-central discussions will be directly involved in >>>> this issue. >>>> It is critical that all of the RIR's have policies establishing a >>>> mechanism >>>> for registering ULA-central prefixes & PI. For those who don't >>>> recall, the >>>> reason ULA-central was tabled was that it was seen as a potential >>>> end-run to >>>> acquire PI space in the absence of appropriate policy to do so out >>>> of a >>>> range recognized for global routing. >>>> >>>> The need for keeping some things local while others are global is >>>> real, and >>>> the lack of appropriate mechanisms to accomplish that through the >>>> routing >>>> system that is designed to deal with path selection leads to entire >>>> industries for fragile work-arounds along with their increased >>>> complexity. >>>> >>>> Tony >>>> >>>> >>>>> -----Original Message----- >>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>> Behalf Of >>>>> vixie at vix.com >>>>> Sent: Thursday, May 10, 2007 9:59 PM >>>>> To: ppml at arin.net >>>>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in >>>>> arstechnica >>>>> (seen on slashdot) >>>>> >>>>> i think that this article will help inform the debate around the >>>>> ipv6 >>>>> transition: >>>>> >>>>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- >>>>> blessing.ars >>>>> _______________________________________________ >>>>> This message sent to you through the ARIN Public Policy Mailing >>>>> List >>>>> (PPML at arin.net). >>>>> Manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/ppml >>>> >>>> _______________________________________________ >>>> This message sent to you through the ARIN Public Policy Mailing >>>> List >>>> (PPML at arin.net). >>>> Manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/ppml >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From dlw+arin at tellme.com Fri May 11 12:06:02 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 11 May 2007 09:06:02 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464425E7.1070305@arin.net> References: <464425E7.1070305@arin.net> Message-ID: <20070511160601.GQ1343@shell01.corp.tellme.com> On Fri, May 11, 2007 at 04:14:31AM -0400, Member Services wrote: > Policy Proposal Name: IPv4 Soft Landing This is, by far, the best idea I've seen along these lines. The staging would enforce a gradual buildup in requirements for further IPv4 allocations, and provides a nice 'carrot and stick' approach to forcing migration to IPv6. Still, as much as I'd like to say I'm in favor of this proposal, I'm hesitant to do so. On philophical grounds, I'm not sure that a soft landing is strictly necessary. When we run out of IPv4 space, we run out of space. Once we're out, does it matter if the landing was hard or soft? As long as we can walk away, it's a good landing, and IPv6 provides an alternative network protocol. If your organization gets screwed by the lack of IPv4 space, perhaps you should have been looking at IPv6 earlier. The other reason I don't think I can quite endorse this proposal is that it is entirely focused on ISPs and PA space. There's no mention of how PI assignments might be handled, and I think that's a fatal flaw. Perhaps a revision to account for that is in order. I'm told that very few PI applicants come back for more space, so we'd have to have a phased policy change that forces initial assignments to be much more difficult to get. (And additional space, too, of course.) I'm not sure that some of the requirements here are useful in PI space. Does it make sense for an initial allocation to be documentably 96% full for a direct assignment? That seems like a difficult barrier, and one that will lead to frustration and operational expense for such organizations. Multi-homed small enterprises will particularly feel that heat. David - if you can fix the PI flaw, I think you have my support on this one. -David From dlw+arin at tellme.com Fri May 11 12:08:57 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 11 May 2007 09:08:57 -0700 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: <20070511160856.GR1343@shell01.corp.tellme.com> I hate to just parrot someone else's comments, but I'm entirely against the entire concept of ULA-central for exactly the reasons Owen outlines below. (Thanks, Owen, for getting that written so I don't have to!) -David On Thu, May 10, 2007 at 11:12:21PM -0700, Owen DeLong wrote: > ULA Central is intended so that some subset of the internet can reliably > use it to interconnect while not being "globally" routed. > > The problem I have with this theory is that the delta between a > collection > of networks routing by mutual agreement and the internet is: > > A. Fuzzy > B. Non-Existant > C. There is no difference > D. Meaningless > E. Any and/or All of the above > > Pick your favorite answer from the above and you've pretty much got it. > If ULA central were limited to not exiting the local AS (in some > meaningful > way, like routers won't forward routes or traffic to ULA addresses to > external > adjacencies), then, I might see it as something other than an end-run on > the RIR process. However, in it's current state of "license for > anyone who > wants to run a competing RIR for networks that choose to interoperate > on this basis" I think it's a pretty bad idea. > > Owen > > > On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: > > > > >I don't understand your point about why ULA need to be registered if > >its not going to be globally routed. Also PI is not the same as ULA - > >PI do come from RIRs and in IPv6 there was no way to get PI (except > >in a few special cases) until recent ARIN's micro-allocation policy. > > > >On Fri, 11 May 2007, Tony Hain wrote: > > > >>I agree that this will help inform the debate, and while Iljitsch > >>did a good > >>job of outlining the issue, he left out a significant point::: > >>People explicitly chose to be in the state of "as there is > >>currently no > >>obvious way to make services only available locally" by insisting > >>that the > >>local-scope addressing range have a global-scope as far as > >>application > >>developers were concerned. Now the application developers are > >>complaining > >>about the consequences of their choice, because the alternative to > >>'no > >>routing path for an attack' is to insert a device that has to make > >>policy > >>decisions with limited information. > >> > >>The current ULA-central discussions will be directly involved in > >>this issue. > >>It is critical that all of the RIR's have policies establishing a > >>mechanism > >>for registering ULA-central prefixes & PI. For those who don't > >>recall, the > >>reason ULA-central was tabled was that it was seen as a potential > >>end-run to > >>acquire PI space in the absence of appropriate policy to do so out > >>of a > >>range recognized for global routing. > >> > >>The need for keeping some things local while others are global is > >>real, and > >>the lack of appropriate mechanisms to accomplish that through the > >>routing > >>system that is designed to deal with path selection leads to entire > >>industries for fragile work-arounds along with their increased > >>complexity. > >> > >>Tony > >> > >> > >>>-----Original Message----- > >>>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>>Behalf Of > >>>vixie at vix.com > >>>Sent: Thursday, May 10, 2007 9:59 PM > >>>To: ppml at arin.net > >>>Subject: [ppml] article about IPv6 vs firewalls vs NAT in > >>>arstechnica > >>>(seen on slashdot) > >>> > >>>i think that this article will help inform the debate around the > >>>ipv6 > >>>transition: > >>> > >>>http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- > >>>blessing.ars > >>>_______________________________________________ > >>>This message sent to you through the ARIN Public Policy Mailing List > >>>(PPML at arin.net). > >>>Manage your mailing list subscription at: > >>>http://lists.arin.net/mailman/listinfo/ppml > >> > >>_______________________________________________ > >>This message sent to you through the ARIN Public Policy Mailing List > >>(PPML at arin.net). > >>Manage your mailing list subscription at: > >>http://lists.arin.net/mailman/listinfo/ppml > >_______________________________________________ > >This message sent to you through the ARIN Public Policy Mailing List > >(PPML at arin.net). > >Manage your mailing list subscription at: > >http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From Kavalec at BSWA.com Fri May 11 13:52:20 2007 From: Kavalec at BSWA.com (G. Waleed Kavalec) Date: Fri, 11 May 2007 11:52:20 -0600 Subject: [ppml] Policy Proposal: IPv4 Soft Landing Message-ID: > As long as we can walk away, it's a good landing, and IPv6 > provides an alternative network protocol. The rub is: who is the "we" referenced here? I support this proposal, exactly because of the carrot/stick it provides; it gives sysadmins across the nation something very tangible to give their management. -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of David Williamson Sent: Friday, May 11, 2007 10:06 AM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing On Fri, May 11, 2007 at 04:14:31AM -0400, Member Services wrote: > Policy Proposal Name: IPv4 Soft Landing This is, by far, the best idea I've seen along these lines. The staging would enforce a gradual buildup in requirements for further IPv4 allocations, and provides a nice 'carrot and stick' approach to forcing migration to IPv6. Still, as much as I'd like to say I'm in favor of this proposal, I'm hesitant to do so. On philophical grounds, I'm not sure that a soft landing is strictly necessary. When we run out of IPv4 space, we run out of space. Once we're out, does it matter if the landing was hard or soft? As long as we can walk away, it's a good landing, and IPv6 provides an alternative network protocol. If your organization gets screwed by the lack of IPv4 space, perhaps you should have been looking at IPv6 earlier. The other reason I don't think I can quite endorse this proposal is that it is entirely focused on ISPs and PA space. There's no mention of how PI assignments might be handled, and I think that's a fatal flaw. Perhaps a revision to account for that is in order. I'm told that very few PI applicants come back for more space, so we'd have to have a phased policy change that forces initial assignments to be much more difficult to get. (And additional space, too, of course.) I'm not sure that some of the requirements here are useful in PI space. Does it make sense for an initial allocation to be documentably 96% full for a direct assignment? That seems like a difficult barrier, and one that will lead to frustration and operational expense for such organizations. Multi-homed small enterprises will particularly feel that heat. David - if you can fix the PI flaw, I think you have my support on this one. -David _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Fri May 11 13:29:04 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 11 May 2007 12:29:04 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing References: Message-ID: <01b201c793f2$db8eb540$523816ac@atlanta.polycom.com> Thus spake "G. Waleed Kavalec" > I support this proposal, exactly because of the carrot/stick it > provides; it gives sysadmins across the nation something very > tangible to give their management. I don't see much of a carrot. The phases are arbitrary from management's perspective since they depend on IANA's actions and what the various RIRs are doing. I'd much, much prefer that specific dates are put on the phases (such as 1 Jan of each year starting in 2009, or something based on current projections) because _that_ is something management can figure in when planning their budgets. I like the idea of progressively tighter requirements as we get closer to exhaustion, and particularly that we are going to tell people what they'll be long in advance of them happening instead of being based on policy action at each meeting, which can't be predicted. There's also no mention of whether this is intended to be retroactive, i.e. interface with potential reclamation activities. If it does, is ARIN supposed to go back and start revoking allocations for people without IPv6 deployment plans the day we hit phase 1? If so, that may affect a lot of people's support for both proposals. I'm also against third-party audits; if we get to the point current review procedures are insufficient due to widespread fraud, we need to debate such a controversial change separately. Also, as David W. mentioned, this doesn't seem to have any consideration for direct assignments, only allocations. If that's the intent, which I'm not sure I agree with, that should be called out. If not, the same requirements don't seem to make sense. Last, this seems to be a global policy, and I understand it's expedient to submit the same proposal to each RIR, but we need someone to revise this to show how it'll fit into the NRPM. I'm currently on the fence, given my issues above, so I am not volunteering for that task. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From marla.azinger at frontiercorp.com Fri May 11 14:38:52 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 11 May 2007 14:38:52 -0400 Subject: [ppml] Reclamation of Number Resources comments Message-ID: <454810F09B5AA04E9D78D13A5C39028A023EF944@nyrofcs2ke2k01.corp.pvt> Proposal: Reclamation of Number Resources. Good job! I would support this policy. I just have a few comments/concerns. I like this proposal and I think the location of it should possibly change in the NRPM. This proposal should be for both IPv4 and IPv6. Is there any reason that this cant be a general policy no matter what type of IP addresses are being used? In fact...I think section 4.1 General principles could be moved out of IPv4 section and just be "general" with a few rewrites in the individual subject matters. I realize that is another task but the point is I think this policy should speak for all IP addresses and not just one version. Here are my comments specific to the proposal text. Line Item 4: I am not sure if the words "whole Delegation" is clear enough. Do you mean a /24? Or do you mean the exact Supernet they were Allocated or Assigned ie a /18 or /12? I think you mean the latter... >may return any number of whole delegations necessary to restore compliance.< Line Item 5: Just out of curiosity...what would the staff operational factors of this be? Would they null route these forced reclaims? >ARIN may revoke any resources as required to bring the organization into compliance.< Line Item 6: This just kinda reads rough. Maybe a more simple way of saying it would be: Return or revocation of resources will be reflected in billing immediatly. >Return or revocation of resources shall be immediate for billing purposes.< Cheers! Marla From marla.azinger at frontiercorp.com Fri May 11 14:39:57 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 11 May 2007 14:39:57 -0400 Subject: [ppml] Removal of ISP Immediate Need from End-User comments Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F8DD@nyrofcs2ke2k01.corp.pvt> .Proposal: Removal of ISP Immediate Need from End-User. Bravo! I would support moving this forward as a policy. Cheers! Marla From drc at virtualized.org Fri May 11 15:09:33 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 11 May 2007 12:09:33 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> Message-ID: <06AE5AC0-CE96-42DE-A7C2-579738321BE3@virtualized.org> Hi, On May 11, 2007, at 5:05 AM, wrote: >> Rationale: > Where is the graphical timeline for this proposal? Graphics are a bit challenging to reproduce in ASCII. However, I'll see what I can do. > Where are the IPv4 runout charts with the phase points superimposed on > them? The IPv4 runout charts are a fiction that make the silly assumption that future behavior depends on past performance. This isn't to say I think that fiction doesn't have value or that the Geoff is wrong in his assumptions (I'd make the same), but even he would, I suspect, agree that the estimates he provides are at best a best case scenario that ignores the socio-economic factors that will likely play an increasingly significant role in address allocations in the relatively near future. > Where is the table that explains this all in a more readable fashion > than plain prose? Well, there was a table, but I had to remove it so the policy proposal could be printed out on ASR-33s and Decwriters. Or something like that. > I know that the policy must be written purely in prose, however the > rationale can and should include other material when trying to explain > something as complex as this proposal. This may point to a flaw in the way policy proposals are published. > Right now, I'd vote against this just because I don't know if I > understand all the implications one way or the other. When in doubt, > stick with the status quo. When one is driving down a road that has a brick wall at the end, the status quo is to set cruise control. It isn't immediately apparent that this can in away be considered "good stewardship". Rgds, -drc From drc at virtualized.org Fri May 11 15:40:30 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 11 May 2007 12:40:30 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <20070511160601.GQ1343@shell01.corp.tellme.com> References: <464425E7.1070305@arin.net> <20070511160601.GQ1343@shell01.corp.tellme.com> Message-ID: Hi, On May 11, 2007, at 9:06 AM, David Williamson wrote: > On Fri, May 11, 2007 at 04:14:31AM -0400, Member Services wrote: >> Policy Proposal Name: IPv4 Soft Landing > > This is, by far, the best idea I've seen along these lines. Thanks. > The > staging would enforce a gradual buildup in requirements for further > IPv4 allocations, and provides a nice 'carrot and stick' approach to > forcing migration to IPv6. Actually, it is more of a "growing stick" approach. The carrot is handled elsewhere (e.g., waiver of IPv6 fees). > Still, as much as I'd like to say I'm in favor of this proposal, I'm > hesitant to do so. On philophical grounds, I'm not sure that a soft > landing is strictly necessary. When we run out of IPv4 space, we run > out of space. Once we're out, does it matter if the landing was hard > or soft? Yes, very, VERY much so. The issue here is that Internet resource management does not operate in a vacuum. There is constant pressure that most of you all don't see for Internet resource management to be done by "professionals", e.g., within national governments, the ITU, other international or inter-governmental treaty organizations, etc. Failure to adequately provide for at least some semblance of a reasonable transition from Internet v1 to Internet v2 will be used as justification for a fundamental restructuring of how Internet resource management is done. To date, there have been no proposals that explicitly try to drive increased deployment of IPv6 as a means to get over the chicken-and- egg problem that has hindered the deployment of IPv6. "IPv4 Soft Landing" is a first, undoubtedly flawed attempt to try to provide real incentive for a transition. > As long as we can walk away, it's a good landing, and IPv6 > provides an alternative network protocol. If your organization gets > screwed by the lack of IPv4 space, perhaps you should have been > looking > at IPv6 earlier. "Hi Grandma. You can't send e-mail? Well, of course not. You didn't deploy IPv6 on your home router. What were you thinking?! Sheesh. By the way, how's that new IP-monitored pacemaker working? Err, hello? Hello?" The vast majority of people using the Internet are not aware and if they were would not care about whether they are using IPv4 or IPv6. What the vast majority of people using the Internet care about is reaching the content that is relevant to them. Saying "you should've known better" when an infrastructure that national economies depend on runs into trouble is the right approach if you want governments involved. IPv6 has created a second Internet. Unfortunately, all the services and content are still on the old Internet. As long as there is no incentive to start populating the Second Internet, people are not going to migrate. Got to break the chicken-and-egg problem somehow... > The other reason I don't think I can quite endorse this proposal is > that it is entirely focused on ISPs and PA space. There's no mention > of how PI assignments might be handled, and I think that's a fatal > flaw. Perhaps a revision to account for that is in order. I'm told > that very few PI applicants come back for more space, so we'd have to > have a phased policy change that forces initial assignments to be much > more difficult to get. (And additional space, too, of course.) This would go against current trends of liberalizing PI allocation policies in all RIRs. One reason I didn't include PI in this proposal is that it was my impression that PI allocations make up a really, really tiny of all address space that is allocated. I thought it best to go for the big targets first. It may be that my assumptions were wrong... ARIN staff might be able to provide input on this. However, with that said, I'm happy to revise the proposal to include a second section that deals with PI. Or, perhaps better, provide a second proposal as adding a second section might trigger Michael Dillon's "too complicated, too long" rants (:-)). (Those rants, by the way, I generally agree with -- policies should be short and to the point). Rgds, -drc From gih at apnic.net Fri May 11 16:02:51 2007 From: gih at apnic.net (Geoff Huston) Date: Sat, 12 May 2007 06:02:51 +1000 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <06AE5AC0-CE96-42DE-A7C2-579738321BE3@virtualized.org> References: <464425E7.1070305@arin.net> <06AE5AC0-CE96-42DE-A7C2-579738321BE3@virtualized.org> Message-ID: <7.0.0.16.2.20070512055434.01428970@apnic.net> > >The IPv4 runout charts are a fiction that make the silly assumption >that future behavior depends on past performance. This isn't to say >I think that fiction doesn't have value or that the Geoff is wrong in >his assumptions (I'd make the same), but even he would, I suspect, >agree that the estimates he provides are at best a best case scenario >that ignores the socio-economic factors that will likely play an >increasingly significant role in address allocations in the >relatively near future. yep - pretty much agreed. The estimates I provide are based on a ;scenario that ignores the socio-economic factors that will likely play an increasingly significant role in address allocations in the relatively near future. Behaviours commonly seen in conjunction with looming exhaustion of a finite resource, such as hoarding and a rush on remaining resources are not included in this model. (last slide of http://www.potaroo.net/presentations/2007-05-09-ripe54-ipv4.pdf) regards, Geoff From drc at virtualized.org Fri May 11 16:02:51 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 11 May 2007 13:02:51 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <01b201c793f2$db8eb540$523816ac@atlanta.polycom.com> References: <01b201c793f2$db8eb540$523816ac@atlanta.polycom.com> Message-ID: Hi, On May 11, 2007, at 10:29 AM, Stephen Sprunk wrote: > I don't see much of a carrot. Right. I don't see the RIRs have much in the way of carrots to provide. I suppose ARIN could start paying people to deploy IPv6, by providing subsidies to fund purchase of IPv6 aware equipment, etc., but I suspect that might run into a bit of resistance from current Beancounters... > The phases are arbitrary from management's > perspective since they depend on IANA's actions and what the > various RIRs > are doing. Yes. The arbitrariness can't really be avoided if you're going to have a phased transition. > I'd much, much prefer that specific dates are put on the phases > (such as 1 Jan of each year starting in 2009, or something based on > current > projections) because _that_ is something management can figure in when > planning their budgets. The difficulty here is that it depends on consumption being something you can reasonably project. Geoff's graphs notwithstanding, this is exceptionally difficult, particularly when socio-economic (read: land rush) factors come into play. There is a bit of Heisenberg here: as people become more aware of the limited nature of the resource, they're going to start hoarding which increases scarcity which causes more people to notice. I suppose both could be used, the threshold and a date, with the first being crossed being the trigger. Not sure if that would address your concern however. > I like the idea of progressively tighter requirements as we get > closer to > exhaustion, and particularly that we are going to tell people what > they'll > be long in advance of them happening instead of being based on > policy action > at each meeting, which can't be predicted. Right. > There's also no mention of whether this is intended to be > retroactive, i.e. > interface with potential reclamation activities. Not sure exactly what you mean. If a threshold is crossed in the "other" direction, that is, say DoD decides they don't want IPv4 anymore and return all of their space, then a case can be made that the restrictions should be relaxed. However, my feeling is that the restrictions should NOT be relaxed, even if a bunch of address space is freed up since I believe we really don't want to have 2 Internets. > I'm also against third-party audits; > if we get to the point current review procedures are insufficient > due to > widespread fraud, we need to debate such a controversial change > separately. This was a late addition to the policy proposal at the suggestion of others who I ran a draft by. The third-party audits are addressing the fact that it is impossible to externally and objectively verify certain aspects of conformance to policy. I'd be happy to include some other mechanism. > Also, as David W. mentioned, this doesn't seem to have any > consideration for > direct assignments, only allocations. If that's the intent, which > I'm not > sure I agree with, that should be called out. If not, the same > requirements > don't seem to make sense. As mentioned in my response to David W., it was intentional. I can either expand on the proposal or add a second proposal. > Last, this seems to be a global policy, and I understand it's > expedient to > submit the same proposal to each RIR, but we need someone to revise > this to > show how it'll fit into the NRPM. I'm currently on the fence, > given my > issues above, so I am not volunteering for that task. If there is a consensus that this isn't a horrible idea, I was planning on submitting it to the other RIRs. Rgds, -drc From dlw+arin at tellme.com Fri May 11 16:11:39 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 11 May 2007 13:11:39 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <7.0.0.16.2.20070512055434.01428970@apnic.net> References: <464425E7.1070305@arin.net> <06AE5AC0-CE96-42DE-A7C2-579738321BE3@virtualized.org> <7.0.0.16.2.20070512055434.01428970@apnic.net> Message-ID: <20070511201139.GA336@shell01.corp.tellme.com> On Sat, May 12, 2007 at 06:02:51AM +1000, Geoff Huston wrote: > The estimates I provide are based on a ;scenario that ignores the > socio-economic factors that will likely play an increasingly > significant role in address allocations in the relatively near future. After reviewing Geoff's latest slides, I think I have another problem with the proposed policy. I think there may be too many phases in this. Based on the timeline involved, we could end up changing policies every two or three months. As some applications may take that long to completely process, that will put staff in the unhappy position of having to figure out which policies go with which applications. Since this can't possibly take effect before about Jan. 1, 2008, that fives us a total of two years before IANA runs out of /8s (ignoring any additional pressure on the system). Perhaps fewer phases would be useful. -David From jmorrison at bogomips.com Fri May 11 16:54:48 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Fri, 11 May 2007 13:54:48 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> <20070511160601.GQ1343@shell01.corp.tellme.com> Message-ID: <4644D818.80505@bogomips.com> There's absolutely no incentive to adopt IPv6. Everyone who needs IPv4 addresses essentially already has them, or has the money to acquire someone who does if they need more. Is an IPv4 shortage really going to stop Google, Microsoft, MCI or a large cable/xDSL service provider from doing business? Giving out more IPv4 addresses just makes the IPv4 club bigger. The day the last IPv4 address is used up, the existing IPv4 Internet doesn't cease to exist, it'll be business as usual for the millions of users and existing services. New users won't be shut out, they'll just be second class citizens and by that time they may not realize it or even care. NAT and as yet undreamed of "technologies" (kludges) designed to preserve IPv4 will be in full swing to keep business as usual. RFC 3021 is one example, RFC 3489 an even better one. The only carrot is IPv4 addresses, and for a soft landing, you need to make new IPv4 address space conditional on deploying IPv6. Even deliberately "wasting" IPv4 space could be strategic in prompting adoption of IPv6 - this could be in the form of waiving regulations and paperwork for service providers who have working IPv6 networks. What is the point of efficiently utilizing and managing IPv4 space if it simply preserves the status quo? At some point, a large ISP or hosting provider should be able to demonstrate that they broadly offer IPv6 DHCP to end users, and have IPv6 accessible DNS and Web services before receiving new IPv4 space. The bigger the existing IPv4 allocation, the more they have at stake it terms of customers and one presumes, of budgets, implementation skills and of an obligation of sorts to adopt IPv6. Conversely, someone with a smaller or no existing IPv4 allocation has no impact at all if they are an early adopter or have IPv6 as some precondition. David Conrad wrote: > Hi, > > On May 11, 2007, at 9:06 AM, David Williamson wrote: > >> On Fri, May 11, 2007 at 04:14:31AM -0400, Member Services wrote: >> >>> Policy Proposal Name: IPv4 Soft Landing >>> >> This is, by far, the best idea I've seen along these lines. >> > > Thanks. > > >> The >> staging would enforce a gradual buildup in requirements for further >> IPv4 allocations, and provides a nice 'carrot and stick' approach to >> forcing migration to IPv6. >> > > Actually, it is more of a "growing stick" approach. The carrot is > handled elsewhere (e.g., waiver of IPv6 fees). > > >> Still, as much as I'd like to say I'm in favor of this proposal, I'm >> hesitant to do so. On philophical grounds, I'm not sure that a soft >> landing is strictly necessary. When we run out of IPv4 space, we run >> out of space. Once we're out, does it matter if the landing was hard >> or soft? >> > > Yes, very, VERY much so. > > The issue here is that Internet resource management does not operate > in a vacuum. There is constant pressure that most of you all don't > see for Internet resource management to be done by "professionals", > e.g., within national governments, the ITU, other international or > inter-governmental treaty organizations, etc. Failure to adequately > provide for at least some semblance of a reasonable transition from > Internet v1 to Internet v2 will be used as justification for a > fundamental restructuring of how Internet resource management is done. > > To date, there have been no proposals that explicitly try to drive > increased deployment of IPv6 as a means to get over the chicken-and- > egg problem that has hindered the deployment of IPv6. "IPv4 Soft > Landing" is a first, undoubtedly flawed attempt to try to provide > real incentive for a transition. > > >> As long as we can walk away, it's a good landing, and IPv6 >> provides an alternative network protocol. If your organization gets >> screwed by the lack of IPv4 space, perhaps you should have been >> looking >> at IPv6 earlier. >> > > "Hi Grandma. You can't send e-mail? Well, of course not. You > didn't deploy IPv6 on your home router. What were you thinking?! > Sheesh. By the way, how's that new IP-monitored pacemaker working? > Err, hello? Hello?" > > The vast majority of people using the Internet are not aware and if > they were would not care about whether they are using IPv4 or IPv6. > What the vast majority of people using the Internet care about is > reaching the content that is relevant to them. Saying "you should've > known better" when an infrastructure that national economies depend > on runs into trouble is the right approach if you want governments > involved. > > IPv6 has created a second Internet. Unfortunately, all the services > and content are still on the old Internet. As long as there is no > incentive to start populating the Second Internet, people are not > going to migrate. Got to break the chicken-and-egg problem somehow... > > >> The other reason I don't think I can quite endorse this proposal is >> that it is entirely focused on ISPs and PA space. There's no mention >> of how PI assignments might be handled, and I think that's a fatal >> flaw. Perhaps a revision to account for that is in order. I'm told >> that very few PI applicants come back for more space, so we'd have to >> have a phased policy change that forces initial assignments to be much >> more difficult to get. (And additional space, too, of course.) >> > > This would go against current trends of liberalizing PI allocation > policies in all RIRs. > > One reason I didn't include PI in this proposal is that it was my > impression that PI allocations make up a really, really tiny of all > address space that is allocated. I thought it best to go for the big > targets first. It may be that my assumptions were wrong... ARIN > staff might be able to provide input on this. > > However, with that said, I'm happy to revise the proposal to include > a second section that deals with PI. Or, perhaps better, provide a > second proposal as adding a second section might trigger Michael > Dillon's "too complicated, too long" rants (:-)). (Those rants, by > the way, I generally agree with -- policies should be short and to > the point). > > Rgds, > -drc > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Fri May 11 17:05:37 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 23:05:37 +0200 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464425E7.1070305@arin.net> Message-ID: I like very much this proposal and will support it. I see only a couple of issues that could easily be resolved in a new revision. 1) I think "plans" is not enough for the ARIN staff to verify, and is an easy path for people to actually "make up" the plans. I will suggest that those plans need to be checked later on and space reclaimed if they aren't being followed. There may be other choices of course. 2) One possibility (will also work for 1) is to actually verify the plans and the IPv6 deployment with a 3rd party audit, same as suggested for IPv4 utilization. Otherwise ARIN staff may have problems to verify everything. Moreover, who is going to pay the 3rd party audit ? I see to choices, the requester itself, or ARIN. I think both have advantages and disadvantages, but I will say that if this is paid by ARIN (which in principle is what I would choose), there is much more control on the audit process. Actually one more possible policy proposal could be to run the audit to all the existing members and use the results in order to reclaim unused space. I will say that in this case the audit should be paid by ARIN for all the members that actually pass it correctly, but by the members itself for those that need to return some space. Regards, Jordi > De: Member Services > Responder a: > Fecha: Fri, 11 May 2007 04:14:31 -0400 > Para: > Asunto: [ppml] Policy Proposal: IPv4 Soft Landing > > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The AC will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is presented; > > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, > > 3. Not accept the proposal as a formal policy proposal. > > The AC will review this proposal at their next regularly scheduled > meeting. If their meeting is within ten days, then the review may be > extended to the subsequent meeting. If the AC accepts the proposal, then > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. If the AC does not accept the > proposal, then the AC will explain that decision; and at that time the > author may elect to use the petition process to advance their proposal. > If the author elects not to petition or the petition fails, then the > proposal will be closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv4 Soft Landing > > Author: David Conrad > > Proposal Version: 1.0 > > Submission Date: 2007-05-02 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > 30 days after specified thresholds in the amount of address space > remaining in the IANA IPv4 free pool are crossed, the requirements > necessary for ISPs to obtain additional IPv4 address space are made > more stringent and requesters must demonstrate efforts both to utilize > scarce IPv4 address space more efficiently, set up IPv6 infrastructure > services, and eventually offer production IPv6 connectivity. > > The proposed thresholds and the requirements to justify an allocation > of new IPv4 address space from ARIN are: > > Phase 0 > Threshold N/A > Requirements > > Requesters must demonstrate: > > * No requirements to document IPv6 infrastructure services or IPv6 > connectivity services. > > * 80% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Downstream immediate requirement: 25% > > * Downstream requirement after 1 year: 50% > > Phase 1 > Threshold 40 /8s > Requirements: > > Requesters must demonstrate: > > * Documented plans for availability of production IPv6 infrastructure > services within 6 months > > * Documented plans for availability of production IPv6 service within > 1 year > > * 85% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Downstream immediate requirement: 33% > > * Downstream requirement after 1 year: 66% > > Phase 2 > Threshold 30 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 infrastructure services > > * Documented plans for availability of production IPv6 service within > 6 months > > * 90% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 50% > > * Downstream requirement after 1 year: 75% > > Phase 3 > Threshold 20 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 infrastructure services > > * Documented availability of production IPv6 connectivity service > > * A migration plan for all internal infrastructure to either IPv6 or > private addressing > > * 92% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 60% > > * Downstream requirement after 1 year: 80% > > Phase 4 > Threshold 15 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 connectivity services > > * Initiation of migration of internal infrastructure to either IPv6 or > private addressing > > * 94% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 70% > > * Downstream requirement after 1 year: 85% > > Internal infrastructure can be used in justification for IPv4 address > space only in special circumstances > > Phase 5 > Threshold 10 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 connectivity services > > * Recycling of 25% of (non-private) IPv4 address space formerly used > for internal infrastructure > > * 96% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 75% > > * Downstream requirement after 1 year: 90% > > Internal infrastructure can no longer be used in justification for > IPv4 address space > > Phase 6 > Threshold 5 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 connectivity services > > * Recycling of 75% of IPv4 address space formerly used for internal > infrastructure > > * 98% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 80% > > * Downstream requirement after 1 year: 95% > > Internal infrastructure can no longer be used in justification for > IPv4 address space > > Note that for the purposes of this proposal, the following definitions > apply: > > * Downstream: entities to which the ISP may assign address space. > > * IPv6 infrastructure services: services such as DNS, WWW, FTP, > etc. accessible via IPv6. > > * IPv6 connectivity: IP connectivity service provided over IPv6 > transport, either natively or via an IPv6 tunnel. > > * Internal infrastructure: routers, switches, servers, etc., that are > not normally visible or directly accessed by the ISP customers. > > Phase 0 reflects current allocation requirements. Subsequent phases > of this policy are to be implemented 30 days after IANA allocates > address space from the IPv4 free pool that reduces that free pool to a > number of /8s that are at or below the threshold specified. If > multiple thresholds should be crossed within a 30 day period, the > requirements from the last threshold crossed will be applied to > requesters for additional address space. > > Rationale: > > The rationale for this proposal is threefold: > > * to prolong the availability of IPv4 addresses to requesters who can > provide sufficient justification; > > * to encourage the deployment of IPv6 as an alternative to IPv4 by > making the requirements to justify IPv4 allocations increasingly > stringent over time; > > * to promote the more efficient use of increasingly scarce IPv4 > resources. > > As the lack of significant deployment of IPv6 can attest, the cost of > deploying IPv6 currently outweighs the benefits that protocol would > appear to provide. This proposal aims to encourage the deployment of > IPv6 by making the allocation of IPv4 both more difficult and > contingent on the ISP demonstrating both support for IPv6 as well as > more efficient use of the IPv4 address space they administer. The > goal of these measures is to rebalance the IPv6 deployment > cost/benefit ratio thereby encouraging greater uptake of IPv6 before > the IPv4 free pool is exhausted. > > The "IPv4 Soft Landing" policy aims to provide for a smoother > transition away from IPv4 towards IPv6 by imposing increasingly strict > requirements for new address allocations as the amount of address > space available in the IANA unallocated IPv4 address pool decreases. > These increased requirements include both more stringent reassignment > and utilization percentages as well as requiring documented IPv6 > infrastructure services and connectivity provision and the reuse of > IPv4 address space used for internal infrastructure. > > The increased stringency in the allocation requirements is intended > both to increase the efficiency of utilization of the IPv4 address > space and to reduce the likelihood of a "run" on the remaining free > pool of IPv4 address space. ARIN staff would be expected to use the > same mechanisms in use today to verify utilization of customer > requirements. > > The requirements for demonstration of IPv6 infrastructure services and > connectivity are intended to motivate ISPs to provide those services > before the only address space they can offer their customers is IPv6, > thereby breaking the "chicken-and-egg" problem limiting significant > IPv6 deployment. Verification of these requirements can be done by > ARIN staff by using IPv6 transport to connect to published services of > the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping > to identified addresses internal to the ISP. > > The requirement to provide a current third-party auditors report of > utilization is intended to deter fraudulent justification data used to > support IPv4 allocations in the absence of actual need. > > The requirements to migrate internal infrastructure to either IPv6 or > private (e.g., RFC 1918) addressing are intended to improve the > efficiency of utilization of IPv4 address space, reserving the scarce > IPv4 resources for purposes for which IPv6 or private addresses are > not suitable. These requirements acknowledge that pragmatically, the > use of IPv4 is absolutely essential only for servers in client-server > architectures, machines engaged in peer-to-peer applications, and > entry points for NAT/ALG devices. As such, use of IPv4 for purposes > such as router interface numbering, client-only devices, and devices > which should not be available from external networks should be > discouraged. This policy anticipates ARIN staff will make use of > auditor reports to verify appropriate use of IPv4 addresses in > internal infrastructure. > > The time for transition between phases of this policy are not fixed, > rather they depend on the rate of consumption of IPv4 address space > from the IANA free pool. Current RIR operational procedure is to > request 2 /8s from the IANA when their current pool of free IPv4 > address space is depleted. This procedure should ensure transitions > between phases will have some lead-time, so organizations can prepare > for the next phase of IPv4 address allocation. > > Timetable for implementation: > > Immediately upon approval of this policy by the ARIN Board of Trustees. > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri May 11 17:13:03 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 23:13:03 +0200 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <01b201c793f2$db8eb540$523816ac@atlanta.polycom.com> Message-ID: I don't think is a good idea to try going for a global policy. It may happen that in some regions don't reach consensus, and even if that happens, it may be slower. I will instead suggest making sure that all the regions adopt it one by one (even if at the end there are some differences among the final text in some of them). Regards, Jordi > De: Stephen Sprunk > Responder a: > Fecha: Fri, 11 May 2007 12:29:04 -0500 > Para: ARIN PPML > Asunto: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > Thus spake "G. Waleed Kavalec" >> I support this proposal, exactly because of the carrot/stick it >> provides; it gives sysadmins across the nation something very >> tangible to give their management. > > I don't see much of a carrot. The phases are arbitrary from management's > perspective since they depend on IANA's actions and what the various RIRs > are doing. I'd much, much prefer that specific dates are put on the phases > (such as 1 Jan of each year starting in 2009, or something based on current > projections) because _that_ is something management can figure in when > planning their budgets. > > I like the idea of progressively tighter requirements as we get closer to > exhaustion, and particularly that we are going to tell people what they'll > be long in advance of them happening instead of being based on policy action > at each meeting, which can't be predicted. > > There's also no mention of whether this is intended to be retroactive, i.e. > interface with potential reclamation activities. If it does, is ARIN > supposed to go back and start revoking allocations for people without IPv6 > deployment plans the day we hit phase 1? If so, that may affect a lot of > people's support for both proposals. I'm also against third-party audits; > if we get to the point current review procedures are insufficient due to > widespread fraud, we need to debate such a controversial change separately. > > Also, as David W. mentioned, this doesn't seem to have any consideration for > direct assignments, only allocations. If that's the intent, which I'm not > sure I agree with, that should be called out. If not, the same requirements > don't seem to make sense. > > Last, this seems to be a global policy, and I understand it's expedient to > submit the same proposal to each RIR, but we need someone to revise this to > show how it'll fit into the NRPM. I'm currently on the fence, given my > issues above, so I am not volunteering for that task. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri May 11 17:14:19 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 23:14:19 +0200 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <20070511201139.GA336@shell01.corp.tellme.com> Message-ID: I believe that this may not be necessarily a problem, even if I will not mind to have less phases if that's agreed. If this works, as we can expect, there is a chance that we delay by a few months the IPv4 exhaustion, so then there should not be a problem to have so many phases. Regards, Jordi > De: David Williamson > Responder a: > Fecha: Fri, 11 May 2007 13:11:39 -0700 > Para: Geoff Huston > CC: > Asunto: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > On Sat, May 12, 2007 at 06:02:51AM +1000, Geoff Huston wrote: >> The estimates I provide are based on a ;scenario that ignores the >> socio-economic factors that will likely play an increasingly >> significant role in address allocations in the relatively near future. > > After reviewing Geoff's latest slides, I think I have another problem > with the proposed policy. I think there may be too many phases in > this. Based on the timeline involved, we could end up changing > policies every two or three months. As some applications may take that > long to completely process, that will put staff in the unhappy position > of having to figure out which policies go with which applications. > > Since this can't possibly take effect before about Jan. 1, 2008, that > fives us a total of two years before IANA runs out of /8s (ignoring > any additional pressure on the system). Perhaps fewer phases would > be useful. > > -David > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri May 11 17:23:26 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 23:23:26 +0200 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Message-ID: I've talked with Leo from IANA about this details a few days ago. Basically there are two choices to make this happen (even both in parallel): 1) The ID becomes an RFC and possibly has further details, as for example a possible split of the FC00 in between several registries, or just a mention of the IANA as to designate the central registry (a single one or distributed across several), with an explicit mention of the RIRs as being that authority. 2) A global policy doing the same job. The risk here is that it is not accepted by any of the RIRs, and then we become stuck. I will say that the RFC path may be faster and actually is what I'm trying to follow with the ID authors. Regards, Jordi > De: Jason Schiller > Responder a: > Fecha: Fri, 11 May 2007 09:05:10 -0400 (EDT) > Para: Owen DeLong > CC: , , "address-policy-wg at ripe.net" > > Asunto: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen > on slashdot) > > Owen, > > I just want to be clear about somehting you said. You view ULA central as > "an end-run on the RIR process." Is this because the expired ULC-central > draft suggests that some new "central allocation authority" be established > to assign these addresses? > > If the draft RFC was resurrected and all references to "cental allocation > authority" and "cental authority" were removed and replaced with clear > text explaining the following: > > - IANA should divide FC00::/8 into eight /11s > - Each RIR would be given one /11 to make ULA-Central assignments > - Three /11s would be held in reserve for new RIRs in the future. > > Would you still think this was an end-run on the RIR process? > > Would you be in support of the draft moving forward? > > Do you think this should not be decided by an RFC, but rather as a global > policy through each of the RIRs? > > If you prefer the RIR process, would you be in favor of a global policy > submitted to ARIN that had the provisions of the expired ULA-central > draft, with the modification of removing "cental authority" and clearly > designating how IANA should divide the space among the existing RIRs? > > ULA-central text snippets below. > > ___Jason > > > > draft-ietf-ipv6-ula-central-01.txt -- section 3.2.1 > "Global IDs should be assigned under the authority of a single > allocation organization because they are pseudo-random and without > any structure. This is easiest to accomplish if there is a single > authority for the assignments." > > draft-ietf-ipv6-ula-central-01.txt -- section 7.0 > > "The IANA is instructed to designate an allocation authority, based on > instructions from the IAB, for centrally assigned Unique Local IPv6 > unicast addresses. This allocation authority shall comply with the > requirements described in Section 3.2 of this document, including in > particular allocation on a permanent basis and with sufficient > provisions to avoid hoarding of numbers. If deemed appropriate, the > authority may also consist of multiple organizations performing the > allocation authority duties. > > The designated allocation authority is required to document how they > will meet the requirements described in Section 3.2 of this document > in an RFC. This RFC will be shepherd through the IETF by the IAB." > > > > > > ========================================================================== > 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, 10 May 2007, Owen DeLong wrote: > >> Date: Thu, 10 May 2007 23:12:21 -0700 >> From: Owen DeLong >> To: "william(at)elan.net" >> Cc: vixie at vix.com, ppml at arin.net, address-policy-wg at ripe.net >> Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica >> (seen on slashdot) >> >> ULA Central is intended so that some subset of the internet can reliably >> use it to interconnect while not being "globally" routed. >> >> The problem I have with this theory is that the delta between a >> collection >> of networks routing by mutual agreement and the internet is: >> >> A. Fuzzy >> B. Non-Existant >> C. There is no difference >> D. Meaningless >> E. Any and/or All of the above >> >> Pick your favorite answer from the above and you've pretty much got it. >> If ULA central were limited to not exiting the local AS (in some >> meaningful >> way, like routers won't forward routes or traffic to ULA addresses to >> external >> adjacencies), then, I might see it as something other than an end-run on >> the RIR process. However, in it's current state of "license for >> anyone who >> wants to run a competing RIR for networks that choose to interoperate >> on this basis" I think it's a pretty bad idea. >> >> Owen >> >> >> On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: >> >>> >>> I don't understand your point about why ULA need to be registered if >>> its not going to be globally routed. Also PI is not the same as ULA - >>> PI do come from RIRs and in IPv6 there was no way to get PI (except >>> in a few special cases) until recent ARIN's micro-allocation policy. >>> >>> On Fri, 11 May 2007, Tony Hain wrote: >>> >>>> I agree that this will help inform the debate, and while Iljitsch >>>> did a good >>>> job of outlining the issue, he left out a significant point::: >>>> People explicitly chose to be in the state of "as there is >>>> currently no >>>> obvious way to make services only available locally" by insisting >>>> that the >>>> local-scope addressing range have a global-scope as far as >>>> application >>>> developers were concerned. Now the application developers are >>>> complaining >>>> about the consequences of their choice, because the alternative to >>>> 'no >>>> routing path for an attack' is to insert a device that has to make >>>> policy >>>> decisions with limited information. >>>> >>>> The current ULA-central discussions will be directly involved in >>>> this issue. >>>> It is critical that all of the RIR's have policies establishing a >>>> mechanism >>>> for registering ULA-central prefixes & PI. For those who don't >>>> recall, the >>>> reason ULA-central was tabled was that it was seen as a potential >>>> end-run to >>>> acquire PI space in the absence of appropriate policy to do so out >>>> of a >>>> range recognized for global routing. >>>> >>>> The need for keeping some things local while others are global is >>>> real, and >>>> the lack of appropriate mechanisms to accomplish that through the >>>> routing >>>> system that is designed to deal with path selection leads to entire >>>> industries for fragile work-arounds along with their increased >>>> complexity. >>>> >>>> Tony >>>> >>>> >>>>> -----Original Message----- >>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>> Behalf Of >>>>> vixie at vix.com >>>>> Sent: Thursday, May 10, 2007 9:59 PM >>>>> To: ppml at arin.net >>>>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in >>>>> arstechnica >>>>> (seen on slashdot) >>>>> >>>>> i think that this article will help inform the debate around the >>>>> ipv6 >>>>> transition: >>>>> >>>>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- >>>>> blessing.ars >>>>> _______________________________________________ >>>>> This message sent to you through the ARIN Public Policy Mailing List >>>>> (PPML at arin.net). >>>>> Manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/ppml >>>> >>>> _______________________________________________ >>>> This message sent to you through the ARIN Public Policy Mailing List >>>> (PPML at arin.net). >>>> Manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/ppml >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> >> > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri May 11 17:32:47 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 23:32:47 +0200 Subject: [ppml] Can the RIRs bypass the IETF and do their own thing? In-Reply-To: Message-ID: I've already indicated this in previous occasions, but may be not in ppml ... We are proceeding in parallel, with the ID and the PDP at the same time. Nothing in the PDP precludes doing so. The RIRs don't depend on IETF at all, they can define global policies for things that the IETF failed to complete if that's the case. IANA can be instructed the same by the RIRs (which a global policy) than by the IETF itself with an RFC. Even when the IETF get the document as an RFC, the RIRs need a policy (in this case no need for a global one) to start using the resource. That's why both things are needed. The boards of the RIRs, if the policy reach consensus, should hold the implementation until the RFC is available or instead, a global policy reach consensus to replace the function of the RFC. This is something that it is natural to be done, but again, doesn't preclude to start debating about the policy and win some time. If anyone want to discuss about the ULA-central ID, I encourage to bring that discussion to the ipv6 WG mailing list, no need to create a new one. For discussions about the policy proposal, use the corresponding RIR mail exploder. Regards, Jordi > De: > Responder a: > Fecha: Fri, 11 May 2007 14:35:25 +0100 > Para: , , > Conversaci?n: Can the RIRs bypass the IETF and do their own thing? > Asunto: Can the RIRs bypass the IETF and do their own thing? > >> If the draft RFC was resurrected > >> Would you still think this was an end-run on the RIR process? >> >> Would you be in support of the draft moving forward? > > Seems to me that if the draft is not resurrected, there are no ULA > addresses for ARIN or RIPE to register, regardless of anything that ARIN > or RIPE members might desire. > >> If you prefer the RIR process, would you be in favor of a global > policy >> submitted to ARIN that had the provisions of the expired ULA-central >> draft, with the modification of removing "cental authority" and > clearly >> designating how IANA should divide the space among the existing RIRs? > > Seems to me that the NRO requires that identical policies be PASSED by > all of the RIRs before they can be considered "global policy". This is > an area where it makes a whole lot of sense to have discussions on > several RIR mailing lists before ANY policy proposal is submitted to ANY > of the 5 RIRs. > > I'm not going to quibble with the wording of the draft at this point. I > just wonder whether it is appropriate for the RIR mailing lists to be > used as a working group for writing Internet drafts? It seems to be a > stupid way to proceed because there are at least 5 different mailing > lists involved, one of which is primarily in Spanish. Crossposting is > not a solution. > > If people are serious about this central ULA concept then they should > get ONE of the RIRs to set up a working group (RIPE would be my first > choice, ARIN second) and then have all of this discussion in that > working group mailing list. People from all of the 5 RIRs should be > invited to the working group by official RIR postings to whatever lists > are appropriate. Some RIRs have announcement lists for such things or > members-only lists to ensure that the word gets out. Then draft the > document in your ONE SINGLE mailing list discussion, submit it to the > IETF, and only then, after an agreed draft is formally in the IETF > pipeline, submit your global policy proposals to each of the RIRs. > > The way this is being done right now is pure madness and I would expect > that the RIR boards will reject any policies that arise through this > UNFAIR AND DISJOINTED process. We have always allowed the IETF to take > first place when it comes to creating new number resources. There is no > good reason to change this for so-called central-ULA addresses. We do > need the technical expertise that is in the IETF to review this before > we can make any kind of policy decisions about a registry for these > addresses. > > I know many people on the RIR policy lists are technical experts, but > that doesn't count, because these are policy lists, not technical ones. > It is one thing for a few technical people to convince a large number of > non-technical people about a topic. It is another thing entirely, for > those few technical people to convince the large number of technical > people who participate in the IETF. It seems to me that the promoters of > central-ULA are trying to bypass the IETF's technical review process and > I don't like this. > > --Michael Dillon > > > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri May 11 17:37:43 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 23:37:43 +0200 Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <90966F89-6CCB-44F5-8797-AD51317E0CC8@delong.com> Message-ID: This is something that could possibly be managed depending on how you setup the fees for ULA-central, but there may be other ways also. I think RIRs staff will make sure that one is not used instead of the other. Fraud (telling you need ULA-central and using as PI) is always a possibility with any policy, and there are means to verify it. I also believe that if transit providers understand the difference, they will not allow using ULA-central as PI, moreover, you will always have the risk of trying so and being filtered in part of the Internet. A PI requester will not risk (unless there is no PI, but now is available already in 3 regions, and I expect that will be in all before ULA-central is adopted in any). Regards, Jordi > De: Owen DeLong > Responder a: > Fecha: Fri, 11 May 2007 06:38:39 -0700 > Para: > CC: , "address-policy-wg at ripe.net" > Asunto: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen > on slashdot) > > > On May 11, 2007, at 1:37 AM, JORDI PALET MARTINEZ wrote: > >> Even if not globally routed, you may want to avoid a possible clash >> with >> another organization, for example in case of a merge. >> >> ULA-central is NOT intended to be uses as IPv6 PI. >> > > Intent is not the problem. Probability of implementation outside of the > intent is the problem. > > ULA Central is only beneficial if it is somehow easier to get than > IPv6 PI. > > If it is easier to get and there is no solid (router-enforced) way to > preclude > it from being "globally routed", then, it will get abused as an > alternative > to IPv6 PI. > > Owen > > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From drc at virtualized.org Fri May 11 17:37:49 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 11 May 2007 14:37:49 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <20070511201139.GA336@shell01.corp.tellme.com> References: <464425E7.1070305@arin.net> <06AE5AC0-CE96-42DE-A7C2-579738321BE3@virtualized.org> <7.0.0.16.2.20070512055434.01428970@apnic.net> <20070511201139.GA336@shell01.corp.tellme.com> Message-ID: <9EF3BFB1-AAB6-43BF-A541-EB6430D776E2@virtualized.org> On May 11, 2007, at 1:11 PM, David Williamson wrote: > As some applications may take that > long to completely process, that will put staff in the unhappy > position > of having to figure out which policies go with which applications. I actually try to address that within the policy: "If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space." The reason for the large number of phases was to try to make the change in requirements gradual instead of big jumps. It might be worth noting that an intended impact of this policy would be to extend the lifetime of the remaining free pool, so Geoff's lifetime projections could become a bit skewed if the policy were implemented. However, I'd be willing to reduce the number of phases if appropriate. I wrote the proposal before Geoff's latest projections were published, so if you believe his numbers, I thought we had more time than we actually do. Rgds, -drc From drc at virtualized.org Fri May 11 17:47:05 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 11 May 2007 14:47:05 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <4644D818.80505@bogomips.com> References: <464425E7.1070305@arin.net> <20070511160601.GQ1343@shell01.corp.tellme.com> <4644D818.80505@bogomips.com> Message-ID: Hi, I'm not sure if you are arguing for or against my proposal. On May 11, 2007, at 1:54 PM, John Paul Morrison wrote: > The only carrot is IPv4 addresses, and for a soft landing, you need > to make new IPv4 address space conditional on deploying IPv6. That's part of the intent of my proposal. > What is the point of efficiently utilizing and managing IPv4 space > if it simply preserves the status quo? Because, as you say, IPv4 isn't going away. The "IPv4 Soft Landing" proposal could've been called "IPv4 Rationing" as if you ignore the requirements to demonstrate IPv6 connectivity and services, that's pretty much what it is. The intent is to try to reserve IPv4 space for what it is absolutely required for, namely servers and NAT/ALG entry points. > At some point, a large ISP or hosting provider should be able to > demonstrate that they broadly offer IPv6 DHCP to end users, and > have IPv6 accessible DNS and Web services before receiving new IPv4 > space. Right. See Phase 3. Rgds, -drc From drc at virtualized.org Fri May 11 17:55:28 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 11 May 2007 14:55:28 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: <6C630CF6-74E9-416C-8518-4B14A6959120@virtualized.org> On May 11, 2007, at 2:05 PM, JORDI PALET MARTINEZ wrote: > I like very much this proposal and will support it. Oh no! It's doomed! :-) More seriously, thanks for the support. > 1) I think "plans" is not enough for the ARIN staff to verify, and > is an > easy path for people to actually "make up" the plans. I will > suggest that > those plans need to be checked later on and space reclaimed if they > aren't > being followed. There may be other choices of course. ... > 2) One possibility (will also work for 1) is to actually verify the > plans > and the IPv6 deployment with a 3rd party audit, same as suggested > for IPv4 > utilization. Otherwise ARIN staff may have problems to verify > everything. I'd ask for input from ARIN staff on this one. > Moreover, who is going to pay the 3rd party audit ? I would assume the requester although I can see arguments for ARIN to pay. Should this be explicit in the policy or should it be left as an implementation choice? Rgds, -drc From drc at virtualized.org Fri May 11 17:56:02 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 11 May 2007 14:56:02 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: <9510D323-35C1-44B4-BFC1-B5AFE698646B@virtualized.org> > I will instead suggest making sure that all the regions adopt it > one by one > (even if at the end there are some differences among the final text > in some > of them). This was my thought. Rgds, -drc From jordi.palet at consulintel.es Fri May 11 18:29:23 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 12 May 2007 00:29:23 +0200 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <6C630CF6-74E9-416C-8518-4B14A6959120@virtualized.org> Message-ID: I will say that the community will benefit from the implementation of this policy, and we want to avoid increasing the "cost" on getting IPv4 address space from the RIR, in such way that the members have less motivation to go for addresses to the secondary market. So I see reasons for ARIN paying that cost. Also if we want to encourage also IPv6 deployment, it is even more sensible that if audits are required to actually check that, they are not an extra cost for the requester. I guess it will be much better to have that defined in the policy. It doesn't hurt if the community agree in this model. But may be the board should tell us if it is appropriate or not (in case not, it could be removed when the final policy text becomes approved). Regards, Jordi > De: David Conrad > Responder a: > Fecha: Fri, 11 May 2007 14:55:28 -0700 > Para: > CC: > Asunto: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > On May 11, 2007, at 2:05 PM, JORDI PALET MARTINEZ wrote: >> I like very much this proposal and will support it. > > Oh no! It's doomed! :-) > > More seriously, thanks for the support. > >> 1) I think "plans" is not enough for the ARIN staff to verify, and >> is an >> easy path for people to actually "make up" the plans. I will >> suggest that >> those plans need to be checked later on and space reclaimed if they >> aren't >> being followed. There may be other choices of course. > ... >> 2) One possibility (will also work for 1) is to actually verify the >> plans >> and the IPv6 deployment with a 3rd party audit, same as suggested >> for IPv4 >> utilization. Otherwise ARIN staff may have problems to verify >> everything. > > I'd ask for input from ARIN staff on this one. > >> Moreover, who is going to pay the 3rd party audit ? > > I would assume the requester although I can see arguments for ARIN to > pay. Should this be explicit in the policy or should it be left as > an implementation choice? > > Rgds, > -drc > > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From drc at virtualized.org Fri May 11 19:02:59 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 11 May 2007 16:02:59 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: Jordi, On May 11, 2007, at 3:29 PM, JORDI PALET MARTINEZ wrote: > I will say that the community will benefit from the implementation > of this > policy, and we want to avoid increasing the "cost" on getting IPv4 > address > space from the RIR, You're missing the point, I suspect. The whole concept behind this policy is to raise the "cost" of obtaining IPv4 space to both decrease IPv4 demand via conservation and increased address space efficiency as well as increase the incentive to migrate to IPv6 by (eventually) making getting IPv4 space contingent on demonstrating IPv6 services and connectivity. The cost can either be in administrative burden needed to justify additional address space or in actual direct (e.g., higher fees) or indirect (e.g., cost of a 3rd party audit) monetary cost. I have avoided the direct cost approach as it gets out of policy and into ARIN operational considerations, leaving increased administrative burden and indirect costs. > in such way that the members have less motivation to go > for addresses to the secondary market. I am assuming people are going to go to the "secondary market" regardless of what the RIRs do. > So I see reasons for ARIN paying that cost. In the end, the requester is going to pay for the 3rd party audit on way or the other, either directly buy paying for it themselves, or by funding it through membership fees (which may need to increase to cover the costs of the audits). My suspicion is that having the requester pay for the audit will be the simplest. > I guess it will be much better to have that defined in the policy. OK. I'd still like to see others' opinions on any one or all of: - whether paying for the audit should be defined in the policy - whether the audit should be paid for by ARIN or the requester - whether there should even be the requirement for the 3rd party audit Thanks, -drc From jordi.palet at consulintel.es Fri May 11 19:16:36 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 12 May 2007 01:16:36 +0200 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: Message-ID: > De: David Conrad > Responder a: > Fecha: Fri, 11 May 2007 16:02:59 -0700 > Para: > CC: > Asunto: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > Jordi, > > On May 11, 2007, at 3:29 PM, JORDI PALET MARTINEZ wrote: >> I will say that the community will benefit from the implementation >> of this >> policy, and we want to avoid increasing the "cost" on getting IPv4 >> address >> space from the RIR, > > You're missing the point, I suspect. The whole concept behind this > policy is to raise the "cost" of obtaining IPv4 space to both > decrease IPv4 demand via conservation and increased address space > efficiency as well as increase the incentive to migrate to IPv6 by No, I got it perfectly, but in my opinion we don't want to raise the cost with the audit, because then it may be cheaper to go to secondary market than the RIR. I'm just trying to find a balance. Of course, may be only my view. > (eventually) making getting IPv4 space contingent on demonstrating > IPv6 services and connectivity. The cost can either be in > administrative burden needed to justify additional address space or > in actual direct (e.g., higher fees) or indirect (e.g., cost of a 3rd > party audit) monetary cost. I have avoided the direct cost approach > as it gets out of policy and into ARIN operational considerations, > leaving increased administrative burden and indirect costs. > >> in such way that the members have less motivation to go >> for addresses to the secondary market. > > I am assuming people are going to go to the "secondary market" > regardless of what the RIRs do. So let's try to avoid it as much as possible, by not increasing the indirect cost. Again is a matter of balance, and is not easy to find the right one. > >> So I see reasons for ARIN paying that cost. > > In the end, the requester is going to pay for the 3rd party audit on > way or the other, either directly buy paying for it themselves, or by > funding it through membership fees (which may need to increase to > cover the costs of the audits). Yes, but shared by all is not going to be so much for each one. Of course, it may happen that most of the membership don't agree on this path ... > > My suspicion is that having the requester pay for the audit will be > the simplest. > >> I guess it will be much better to have that defined in the policy. > > OK. I'd still like to see others' opinions on any one or all of: > > - whether paying for the audit should be defined in the policy > - whether the audit should be paid for by ARIN or the requester > - whether there should even be the requirement for the 3rd party audit What about asking also for if we want the actual IPv6 deployment being audited ? For example, one choice may be each requester pay for the IPv4 audit cost, but in order to help with the IPv6 deployment, the IPv6 audit is paid by the community (unless the audit demonstrates that there is not such deployment !). > > Thanks, > -drc > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From sleibrand at internap.com Sat May 12 01:30:01 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 11 May 2007 22:30:01 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464425E7.1070305@arin.net> References: <464425E7.1070305@arin.net> Message-ID: <464550D9.1040506@internap.com> I would support this policy proposal, or one substantially similar. Thanks for putting it forward. David, one suggestion for fine-tuning the policy: Once there's been time for feedback to bring up various points of detail, you might want to construct a survey, as Andrew Dul did for the IPv6 PI policy, to break out all of the points over which we might quibble and get everyone's opinion on each point. That seemed to me like a very effective way to get consensus on the fine points of a detailed proposal, and helped ensure overall consensus in favor of the proposal at the meeting. -Scott Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The AC will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is presented; > > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, > > 3. Not accept the proposal as a formal policy proposal. > > The AC will review this proposal at their next regularly scheduled > meeting. If their meeting is within ten days, then the review may be > extended to the subsequent meeting. If the AC accepts the proposal, then > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. If the AC does not accept the > proposal, then the AC will explain that decision; and at that time the > author may elect to use the petition process to advance their proposal. > If the author elects not to petition or the petition fails, then the > proposal will be closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv4 Soft Landing > > Author: David Conrad > > Proposal Version: 1.0 > > Submission Date: 2007-05-02 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > 30 days after specified thresholds in the amount of address space > remaining in the IANA IPv4 free pool are crossed, the requirements > necessary for ISPs to obtain additional IPv4 address space are made > more stringent and requesters must demonstrate efforts both to utilize > scarce IPv4 address space more efficiently, set up IPv6 infrastructure > services, and eventually offer production IPv6 connectivity. > > The proposed thresholds and the requirements to justify an allocation > of new IPv4 address space from ARIN are: > > Phase 0 > Threshold N/A > Requirements > > Requesters must demonstrate: > > * No requirements to document IPv6 infrastructure services or IPv6 > connectivity services. > > * 80% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Downstream immediate requirement: 25% > > * Downstream requirement after 1 year: 50% > > Phase 1 > Threshold 40 /8s > Requirements: > > Requesters must demonstrate: > > * Documented plans for availability of production IPv6 infrastructure > services within 6 months > > * Documented plans for availability of production IPv6 service within > 1 year > > * 85% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Downstream immediate requirement: 33% > > * Downstream requirement after 1 year: 66% > > Phase 2 > Threshold 30 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 infrastructure services > > * Documented plans for availability of production IPv6 service within > 6 months > > * 90% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 50% > > * Downstream requirement after 1 year: 75% > > Phase 3 > Threshold 20 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 infrastructure services > > * Documented availability of production IPv6 connectivity service > > * A migration plan for all internal infrastructure to either IPv6 or > private addressing > > * 92% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 60% > > * Downstream requirement after 1 year: 80% > > Phase 4 > Threshold 15 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 connectivity services > > * Initiation of migration of internal infrastructure to either IPv6 or > private addressing > > * 94% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 70% > > * Downstream requirement after 1 year: 85% > > Internal infrastructure can be used in justification for IPv4 address > space only in special circumstances > > Phase 5 > Threshold 10 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 connectivity services > > * Recycling of 25% of (non-private) IPv4 address space formerly used > for internal infrastructure > > * 96% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 75% > > * Downstream requirement after 1 year: 90% > > Internal infrastructure can no longer be used in justification for > IPv4 address space > > Phase 6 > Threshold 5 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 connectivity services > > * Recycling of 75% of IPv4 address space formerly used for internal > infrastructure > > * 98% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 80% > > * Downstream requirement after 1 year: 95% > > Internal infrastructure can no longer be used in justification for > IPv4 address space > > Note that for the purposes of this proposal, the following definitions > apply: > > * Downstream: entities to which the ISP may assign address space. > > * IPv6 infrastructure services: services such as DNS, WWW, FTP, > etc. accessible via IPv6. > > * IPv6 connectivity: IP connectivity service provided over IPv6 > transport, either natively or via an IPv6 tunnel. > > * Internal infrastructure: routers, switches, servers, etc., that are > not normally visible or directly accessed by the ISP customers. > > Phase 0 reflects current allocation requirements. Subsequent phases > of this policy are to be implemented 30 days after IANA allocates > address space from the IPv4 free pool that reduces that free pool to a > number of /8s that are at or below the threshold specified. If > multiple thresholds should be crossed within a 30 day period, the > requirements from the last threshold crossed will be applied to > requesters for additional address space. > > Rationale: > > The rationale for this proposal is threefold: > > * to prolong the availability of IPv4 addresses to requesters who can > provide sufficient justification; > > * to encourage the deployment of IPv6 as an alternative to IPv4 by > making the requirements to justify IPv4 allocations increasingly > stringent over time; > > * to promote the more efficient use of increasingly scarce IPv4 > resources. > > As the lack of significant deployment of IPv6 can attest, the cost of > deploying IPv6 currently outweighs the benefits that protocol would > appear to provide. This proposal aims to encourage the deployment of > IPv6 by making the allocation of IPv4 both more difficult and > contingent on the ISP demonstrating both support for IPv6 as well as > more efficient use of the IPv4 address space they administer. The > goal of these measures is to rebalance the IPv6 deployment > cost/benefit ratio thereby encouraging greater uptake of IPv6 before > the IPv4 free pool is exhausted. > > The "IPv4 Soft Landing" policy aims to provide for a smoother > transition away from IPv4 towards IPv6 by imposing increasingly strict > requirements for new address allocations as the amount of address > space available in the IANA unallocated IPv4 address pool decreases. > These increased requirements include both more stringent reassignment > and utilization percentages as well as requiring documented IPv6 > infrastructure services and connectivity provision and the reuse of > IPv4 address space used for internal infrastructure. > > The increased stringency in the allocation requirements is intended > both to increase the efficiency of utilization of the IPv4 address > space and to reduce the likelihood of a "run" on the remaining free > pool of IPv4 address space. ARIN staff would be expected to use the > same mechanisms in use today to verify utilization of customer > requirements. > > The requirements for demonstration of IPv6 infrastructure services and > connectivity are intended to motivate ISPs to provide those services > before the only address space they can offer their customers is IPv6, > thereby breaking the "chicken-and-egg" problem limiting significant > IPv6 deployment. Verification of these requirements can be done by > ARIN staff by using IPv6 transport to connect to published services of > the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping > to identified addresses internal to the ISP. > > The requirement to provide a current third-party auditors report of > utilization is intended to deter fraudulent justification data used to > support IPv4 allocations in the absence of actual need. > > The requirements to migrate internal infrastructure to either IPv6 or > private (e.g., RFC 1918) addressing are intended to improve the > efficiency of utilization of IPv4 address space, reserving the scarce > IPv4 resources for purposes for which IPv6 or private addresses are > not suitable. These requirements acknowledge that pragmatically, the > use of IPv4 is absolutely essential only for servers in client-server > architectures, machines engaged in peer-to-peer applications, and > entry points for NAT/ALG devices. As such, use of IPv4 for purposes > such as router interface numbering, client-only devices, and devices > which should not be available from external networks should be > discouraged. This policy anticipates ARIN staff will make use of > auditor reports to verify appropriate use of IPv4 addresses in > internal infrastructure. > > The time for transition between phases of this policy are not fixed, > rather they depend on the rate of consumption of IPv4 address space > from the IANA free pool. Current RIR operational procedure is to > request 2 /8s from the IANA when their current pool of free IPv4 > address space is depleted. This procedure should ensure transitions > between phases will have some lead-time, so organizations can prepare > for the next phase of IPv4 address allocation. > > Timetable for implementation: > > Immediately upon approval of this policy by the ARIN Board of Trustees. > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From plzak at arin.net Sun May 13 04:10:29 2007 From: plzak at arin.net (Ray Plzak) Date: Sun, 13 May 2007 04:10:29 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: drc - are you concerned about auditor certification? Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > David Conrad > Sent: Friday, May 11, 2007 7:03 PM > To: jordi.palet at consulintel.es > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > Jordi, > > On May 11, 2007, at 3:29 PM, JORDI PALET MARTINEZ wrote: > > I will say that the community will benefit from the implementation > > of this > > policy, and we want to avoid increasing the "cost" on getting IPv4 > > address > > space from the RIR, > > You're missing the point, I suspect. The whole concept behind this > policy is to raise the "cost" of obtaining IPv4 space to both > decrease IPv4 demand via conservation and increased address space > efficiency as well as increase the incentive to migrate to IPv6 by > (eventually) making getting IPv4 space contingent on demonstrating > IPv6 services and connectivity. The cost can either be in > administrative burden needed to justify additional address space or > in actual direct (e.g., higher fees) or indirect (e.g., cost of a 3rd > party audit) monetary cost. I have avoided the direct cost approach > as it gets out of policy and into ARIN operational considerations, > leaving increased administrative burden and indirect costs. > > > in such way that the members have less motivation to go > > for addresses to the secondary market. > > I am assuming people are going to go to the "secondary market" > regardless of what the RIRs do. > > > So I see reasons for ARIN paying that cost. > > In the end, the requester is going to pay for the 3rd party audit on > way or the other, either directly buy paying for it themselves, or by > funding it through membership fees (which may need to increase to > cover the costs of the audits). > > My suspicion is that having the requester pay for the audit will be > the simplest. > > > I guess it will be much better to have that defined in the policy. > > OK. I'd still like to see others' opinions on any one or all of: > > - whether paying for the audit should be defined in the policy > - whether the audit should be paid for by ARIN or the requester > - whether there should even be the requirement for the 3rd party audit > > Thanks, > -drc > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From bmanning at karoshi.com Mon May 14 01:30:40 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Mon, 14 May 2007 05:30:40 +0000 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: Message-ID: <20070514053040.GA18747@vacation.karoshi.com.> > > ULA-central is NOT intended to be uses as IPv6 PI. but there is no way to stop it from becoming so. From michael.dillon at bt.com Mon May 14 03:27:32 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 14 May 2007 08:27:32 +0100 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <06AE5AC0-CE96-42DE-A7C2-579738321BE3@virtualized.org> References: <464425E7.1070305@arin.net> <06AE5AC0-CE96-42DE-A7C2-579738321BE3@virtualized.org> Message-ID: > > Where is the graphical timeline for this proposal? > > Graphics are a bit challenging to reproduce in ASCII. However, I'll > see what I can do. Please, not ASCII! > > I know that the policy must be written purely in prose, however the > > rationale can and should include other material when trying to explain > > something as complex as this proposal. > > This may point to a flaw in the way policy proposals are published. Or maybe not everyone remembers precedents. Three years ago I proposed a policy which required something more than prose to explain the rationale. ARIN added a page to the website to hold some PERL source code, a couple of spreadsheets and an extended explanation. Here is the proposal with a link way down at the bottom of the page: http://www.arin.net/policy/proposals/2004_2.html I would hate to see ASCII diagrams or tables that depend on fixed-width fonts. But anything that is generally seen on a 21st century web page would be fine with me. Even if you disagree with Geoff's analysis (and his is not the only one), it still would be useful to show some graphs with your key policy dates superimposed on them. Or, if you think you have a better analysis than Geoff, then please show us your graph. --Michael Dillon From michael.dillon at bt.com Mon May 14 04:46:56 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 14 May 2007 09:46:56 +0100 Subject: [ppml] Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: > If anyone want to discuss about the ULA-central ID, I encourage to bring > that discussion to the ipv6 WG mailing list, no need to create a new one. > For discussions about the policy proposal, use the corresponding RIR mail > exploder. I don't know if Fred Baker's message on the IETF list made it to the RIR lists, but he offers a single central discussion place for the central ULA concept. -----quoted from IETF list--------- In your email, you noted the disjoint nature of the RIRs and the need to cross-post or whatever. Speaking as chair of IPv6 Operations (v6ops at ops.ietf.org), I would invite you and all those interested in the effort to use the v6ops list for the purpose and the v6ops working group as a venue to do the work. If you would like, we can arrange a v6ops interim meeting at the RIR meeting of your choice, or it could be discussed in the currently-planned meeting in the third week of July in Chicago. --------------- So, now there is no longer any need to complain that the IETF is too slow or that the RIRs need to work in parallel. Anyone can join the v6ops list (instructions here http://www.ietf.org/html.charters/v6ops-charter.html ) and anyone can propose how central ULAs could be made to work. And for those who wish to meet face-to-face, there is an opportunity in Chicago in July. Hopefully, the v6ops list will look at other alternatives such as using AS numbers to define a block of addresses similar to the way GLOP defined multicast addressing in RFC 3180 http://www.ietf.org/rfc/rfc3180.txt --Michael Dillon From jordi.palet at consulintel.es Mon May 14 04:53:50 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 14 May 2007 10:53:50 +0200 Subject: [ppml] Can the RIRs bypass the IETF and do their own thing? In-Reply-To: Message-ID: That may be true for IPv6 operational issues, however, following the IETF procedures, for discussing about ULA-central, which is an IPv6 WG item, it should be done at the ipv6 at ietf.org mail exploder. Regards, Jordi > De: > Responder a: > Fecha: Mon, 14 May 2007 09:46:56 +0100 > Para: , > Conversaci?n: [ppml] Can the RIRs bypass the IETF and do their own thing? > Asunto: Re: [ppml] Can the RIRs bypass the IETF and do their own thing? > > >> If anyone want to discuss about the ULA-central ID, I encourage to > bring >> that discussion to the ipv6 WG mailing list, no need to create a new > one. >> For discussions about the policy proposal, use the corresponding RIR > mail >> exploder. > > I don't know if Fred Baker's message on the IETF list made it to the RIR > lists, but he offers a single central discussion place for the central > ULA concept. > > -----quoted from IETF list--------- > In your email, you noted the disjoint nature of the RIRs and the need to > cross-post or whatever. Speaking as chair of IPv6 Operations > (v6ops at ops.ietf.org), I would invite you and all those interested in the > effort to use the v6ops list for the purpose and the v6ops working group > as a venue to do the work. If you would like, we can arrange a v6ops > interim meeting at the RIR meeting of your choice, or it could be > discussed in the currently-planned meeting in the third week of July in > Chicago. > --------------- > > So, now there is no longer any need to complain that the IETF is too > slow or that the RIRs need to work in parallel. Anyone can join the > v6ops list (instructions here > http://www.ietf.org/html.charters/v6ops-charter.html ) and anyone can > propose how central ULAs could be made to work. And for those who wish > to meet face-to-face, there is an opportunity in Chicago in July. > > Hopefully, the v6ops list will look at other alternatives such as using > AS numbers to define a block of addresses similar to the way GLOP > defined multicast addressing in RFC 3180 > http://www.ietf.org/rfc/rfc3180.txt > > --Michael Dillon > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From stephen at sprunk.org Mon May 14 08:45:41 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 14 May 2007 07:45:41 -0500 Subject: [ppml] Can the RIRs bypass the IETF and do their own thing? References: <4BEE8CD2-4F61-41AA-B502-631E99411F15@cisco.com> <46484A54.6050806@zurich.ibm.com> Message-ID: <007c01c7962b$0d61c5a0$463816ac@atlanta.polycom.com> Thus spake "Brian E Carpenter" > Fred, the point is that ULAs should be unambiguous, so that if they > happen to meet (e.g. via a VPN, or following a merge of two previously > separate networks) there is no collision. Currently ULAs include > a pseudo-random prefix, which leaves open a theoretical possibility > of collision. Centrally-allocated ULAs would not have this issue. The chance is negligible until you have a number of organizations interconnecting that approaches the AS count on the public Internet. Those who are uncomfortable with those odds can get PIv6 space. ULA Central does not solve any problems that the existing tools already solve, and it creates new problems of its own. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From rich at nic.umass.edu Mon May 14 10:20:04 2007 From: rich at nic.umass.edu (Rich Emmings) Date: Mon, 14 May 2007 10:20:04 -0400 (EDT) Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464425E7.1070305@arin.net> References: <464425E7.1070305@arin.net> Message-ID: Opposed as written. It a poorly conceived idea when it was "2007-12 IPv4 Countdown Policy Proposal", and the changes do not address the weaknesses in 2007-12. Comments: 1) Based on conversations, I get the impression that most folks proposing implementation IPv6, _probably_ have not tried to implement IPv6 on any large scale. ping6 -I eth0 fe80::xxxxxxxxxxxxxxxx doesn't count. (I will grant I could be wrong on this, hence "probably".) 2) Artifically making a commodity rare, will cause a run on it before it's rare and push up the dates. In order to provide something constructive, I think these policy proposals attempt to bite off too much. Break it down into 3 separate ones. First, define events on the use curve. (BTW, it's logistic, not exponential) Not only when we think we need to change policy, but why? Maybe we only define one point in time for now, and just stay focused on what we need to do to not get there. Next, define different policies that ARIN can use with regard to space assignment. Whether you have a /16 or a IPv6 network might be the factors that come up here, or whether it's a time based allocation -- you get a /16 for 2 years then have to return it, or some other agreed-to space, if you're asking for some swing space while you do something else. Last, tie the first event to policies. Once we approach that event in time, we have a track record, and can discuss the next best policy to proceed with. Discussing actions seperately from events, allows them to be fully discussed with the ramifications, without getting into the side issues of when things turn bad. Discussing the events allows a cleaner discussion of growth, live data, models and expectations. Bringing it together last, allows a discussion of what-when. If things are that rotten, then it may be that assignment policies change now, even before the next event. On Fri, 11 May 2007, 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. > > > Policy Proposal Name: IPv4 Soft Landing > > Author: David Conrad > > Proposal Version: 1.0 > > Submission Date: 2007-05-02 > > Proposal type: New > > Policy term: Permanent From stephen at sprunk.org Mon May 14 10:24:19 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 14 May 2007 09:24:19 -0500 Subject: [ppml] Can the RIRs bypass the IETF and do their own thing? References: <4BEE8CD2-4F61-41AA-B502-631E99411F15@cisco.com><46484A54.6050806@zurich.ibm.com> <007c01c7962b$0d61c5a0$463816ac@atlanta.polycom.com> Message-ID: <00dc01c79634$21010810$463816ac@atlanta.polycom.com> Thus spake "Stephen Sprunk" > ULA Central does not solve any problems that the existing tools > already solve, and it creates new problems of its own. That should be "don't already solve". S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From kyle_jones at wonderworks.com Mon May 14 13:43:31 2007 From: kyle_jones at wonderworks.com (Kyle Jones) Date: Mon, 14 May 2007 10:43:31 -0700 Subject: [ppml] help with the acronyms? Message-ID: <17992.40899.677781.454559@lucifer.wonderworks.com> Is there a glossary somewhere that explains ULA, RIR, NRO, ASO, MoU, etc? From BillD at cait.wustl.edu Mon May 14 14:31:48 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 14 May 2007 13:31:48 -0500 Subject: [ppml] help with the acronyms? In-Reply-To: <17992.40899.677781.454559@lucifer.wonderworks.com> Message-ID: Hi Kyle, Alas, the bane of TLAs (three letter acronyms). There are good reference books that reference many (like Newton's Telecom Dictionary) but are always out of date by the nature of things. Wikipedia also has many, but generally only for larger scope entities. ARIN has been underway for a while at creating a glossary. I find that you can generally get the answer you want by simply doing a web search with your favorite tool and by including one other 'context' item....using Google.. ULA + IPv6 gives you a reference, RIR is second on the list, NRO is fourth on the list, but adding IP gets it up to number 1, ASO is harder.... ASO + addresses, works fine.... MoU comes up first when searched. Of course, asking on the list is not forbidden and most would be happy to respond to your inquiry without derision. Finally, many of these entities referenced often in relation to ARIN and addressing policy can be found (along with context) under Reference Documents off the main page of the ARIN website www.arin.net Hang in there Kyle....we need you on the list and involved with addressing policy! Bill Darte ARIN AC (Advisory Council) > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Kyle Jones > Sent: Monday, May 14, 2007 12:44 PM > To: ppml at arin.net > Subject: [ppml] help with the acronyms? > > > Is there a glossary somewhere that explains ULA, RIR, NRO, > ASO, MoU, etc? _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). Manage your mailing list > subscription at: http://lists.arin.net/mailman/listinfo/ppml > From kkargel at polartel.com Mon May 14 14:39:01 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 14 May 2007 13:39:01 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706F17@mail> I still think that all we have to do is do nothing with IPv4, stop improving and adding management, let it die a slow death by attrition, while at the same time making IPv6 easier to use and educating people on the network enhancements that IPv6 provides. What we will see is that the big money boys with R&D teams and budgets will migrate to IPv6, their indispensable services will begin to be more easily available on IPv6 than they are via IPv4, and the small networks will have to either migrate to keep up or suffer a life of segregation (or pay big fees to gateway services). Just as consumers naturally migrated from Beta to VHS because of content, from LP's to tape to CD because of content, and from Win98 to WinXP because of content and services and support, so will consumers migrate to IPv6 when it is easier and offers advantages. It would be much better for the internet community if we avoided the temptations of ego and control, and concentrated on architecture more than management. Build the product before we try to force the market. Kevin $s/worry/happy,g > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David Conrad > Sent: Friday, May 11, 2007 3:03 PM > To: Stephen Sprunk > Cc: ARIN PPML > Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > Hi, > > On May 11, 2007, at 10:29 AM, Stephen Sprunk wrote: > > I don't see much of a carrot. > > Right. I don't see the RIRs have much in the way of carrots > to provide. I suppose ARIN could start paying people to > deploy IPv6, by providing subsidies to fund purchase of IPv6 > aware equipment, etc., but I suspect that might run into a > bit of resistance from current Beancounters... > > > The phases are arbitrary from management's perspective since they > > depend on IANA's actions and what the various RIRs are doing. > > Yes. The arbitrariness can't really be avoided if you're > going to have a phased transition. > > > I'd much, much prefer that specific dates are put on the > phases (such > > as 1 Jan of each year starting in 2009, or something based > on current > > projections) because _that_ is something management can > figure in when > > planning their budgets. > > The difficulty here is that it depends on consumption being > something you can reasonably project. Geoff's graphs > notwithstanding, this is exceptionally difficult, > particularly when socio-economic (read: land > rush) factors come into play. There is a bit of Heisenberg > here: as people become more aware of the limited nature of > the resource, they're going to start hoarding which increases > scarcity which causes more people to notice. > > I suppose both could be used, the threshold and a date, with > the first being crossed being the trigger. Not sure if that > would address your concern however. > > > I like the idea of progressively tighter requirements as we > get closer > > to exhaustion, and particularly that we are going to tell > people what > > they'll be long in advance of them happening instead of > being based on > > policy action at each meeting, which can't be predicted. > > Right. > > > There's also no mention of whether this is intended to be > retroactive, > > i.e. > > interface with potential reclamation activities. > > Not sure exactly what you mean. > > If a threshold is crossed in the "other" direction, that is, > say DoD decides they don't want IPv4 anymore and return all > of their space, > then a case can be made that the restrictions should be relaxed. > However, my feeling is that the restrictions should NOT be > relaxed, even if a bunch of address space is freed up since I > believe we really don't want to have 2 Internets. > > > I'm also against third-party audits; > > if we get to the point current review procedures are > insufficient due > > to widespread fraud, we need to debate such a controversial change > > separately. > > This was a late addition to the policy proposal at the > suggestion of others who I ran a draft by. The third-party > audits are addressing the fact that it is impossible to > externally and objectively verify certain aspects of > conformance to policy. I'd be happy to include some other mechanism. > > > Also, as David W. mentioned, this doesn't seem to have any > > consideration for direct assignments, only allocations. If > that's the > > intent, which I'm not sure I agree with, that should be > called out. > > If not, the same requirements don't seem to make sense. > > As mentioned in my response to David W., it was intentional. > I can either expand on the proposal or add a second proposal. > > > Last, this seems to be a global policy, and I understand it's > > expedient to submit the same proposal to each RIR, but we > need someone > > to revise this to show how it'll fit into the NRPM. I'm > currently on > > the fence, given my issues above, so I am not volunteering for that > > task. > > If there is a consensus that this isn't a horrible idea, I > was planning on submitting it to the other RIRs. > > Rgds, > -drc > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Mon May 14 15:01:13 2007 From: randy at psg.com (Randy Bush) Date: Mon, 14 May 2007 21:01:13 +0200 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066706F17@mail> References: <70DE64CEFD6E9A4EB7FAF3A063141066706F17@mail> Message-ID: <4648B1F9.3010206@psg.com> Kevin Kargel wrote: > I still think that all we have to do is do nothing with IPv4, stop > improving and adding management, let it die a slow death by attrition i wish all my competitors had that attitude. let the customers die by attrition. many of us are foolish enough to think our jobs are about making the net work and keeping our customers successful and happy, and not about the latest religious fervor. silly we. randy From dean at av8.com Mon May 14 15:04:19 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 14 May 2007 15:04:19 -0400 (EDT) Subject: [ppml] Can the RIRs bypass the IETF and do their own thing? In-Reply-To: <46484947.6090702@zurich.ibm.com> Message-ID: > Not quite. The RIRs have authority delegated to them by IANA, and IANA > operates under the terms of its MoU and SLA with the IETF. So the RIRs' > scope is to set and implement policy within their delegated authority, > which itself has to be within the terms of the IANA MoU and SLA. I looked into this some time ago, and found that the U.S. Department of Commerce delegated authority to ICANN, and that ICANN delegated to the RIRs. According to IANA, IANA is just the bookkeeper, and is run by ICANN under contract with the U.S. Government: According documents at http://www.icann.org/general/agreements.htm ICANN contracted with the U.S. Government to handle the IANA function. According to one MoU, the IETF "appointed" ICANN to perform IANA functions, however, there seems to be no authority for IETF to make such a delegation. This MoU is just a notice that the IETF concurs with the award of the U.S. Goverment contract. Using the word "appointed" doesn't mean the IETF has any actual authority to make appointments or to appoint someone else. I note that the IANA physical address is the same as ICANN: Internet Assigned Numbers Authority 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA +1-310-823-9358 (phone) +1-310-823-8649 (facsimile) The agreements that I've found with ICANN, e.g. http://www.icann.org/general/ietf-iana-agreement-v8.htm place the IETF as a technical collaborator to assist ICANN with the IANA function. The IETF provides technical experts to the ICANN/IANA. The IETF is just a technical consultant on IANA functions. Administative authority over RIRs resides in ICANN, and above ICANN, the U.S. Government. ICANN can end the MoU at any time, and find a new technical consultant. The IETF can also end the MoU at any time. But the IETF doesn't have the authority to appoint a new IANA operator. > In this case, I would check out section 4.3 of RFC 2860, especially > the clause (b) in the second paragraph. It's clear to me that centrally- > allocated ULAs are in IETF scope under that clause. Nothing in these MoUs supercede the U.S. Government contracts and agreements that delegate the actual final authority. Also, RFC2860 is superceded by the January 2007 MoU that I cited above. The authority goes top down: US Government ICANN RIRs The RIR's can do whatever ICANN and the US Government allow them to do. The IETF _can_ be taken out of the picture if there is cause to do so. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From jmorrison at bogomips.com Mon May 14 15:42:41 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Mon, 14 May 2007 12:42:41 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> Message-ID: <4648BBB1.5050700@bogomips.com> 1. If you are going to try and push people on to IPv6, it makes sense to start at the top. ISPs, carriers, and hosting providers with the largest allocations will likely have more customers dependent on them, more of their business at stake, and will also have more in house expertise. They need IPv4 to do new business, so make their business dependent on IPv6 and they will have a motivation, as well as the means to do it. End users should receive IPv6 addresses bundled with new IPv4 allocations, but end users can't even begin to drive demand unless there's an IPv6 backbone and some services out there. 2. That may be the point. While there are IPv4 addresses still around, there's leverage. The last available IPv4 address will have the most leverage, but once it's gone, there's no more leverage. I think there's a very big assumption that IPv4 address exhaustion is the end of the world and that IPv6 is guaranteed to replace it in a reasonable time what that event does happen. Maybe there will be a huge Y2K like sense of urgency and effort to replace and upgrade everything, but maybe there'll just be more demand to tweak and fiddle with IPv4 to keep it running just a bit longer. And end users don't need routable IP addresses do they? We can NAT them all or just charge more. Why give end users routable and valuable IPv4 addresses when they will just use them for peer-to-peer copyright violations and/or trying to avoid censorship? So I think there's two approaches - either do nothing, and hope it all works out - IPv6 should win out, but I think there's a chance that IPv4 could be around forever - there's enough invested in it and enough motivation to keep what's good enough working a while longer. If ARIN is going to do something to replace IPv4 with IPv6, then there has to be a fixed criteria, but preferably a fixed date. With a fixed date, people can scramble Y2K like to make the cutoff. If ARIN isn't going to do anything, then that would still be useful to spell out in policy - i.e. we're handing out addresses as needed, until the last IPv4 address is gone, then it's on to IPv6 - let the market sort out the transition. Or the policy might be at least be to reserve the last /8 and suspend all existing IPv4 allocation policies at that point - ie require case by case, committee approval. Rich Emmings wrote: > Opposed as written. > > It a poorly conceived idea when it was "2007-12 IPv4 Countdown Policy Proposal", and the changes do not address the weaknesses in 2007-12. > > Comments: > > 1) Based on conversations, I get the impression that most folks proposing > implementation IPv6, _probably_ have not tried to implement IPv6 on any > large scale. ping6 -I eth0 fe80::xxxxxxxxxxxxxxxx doesn't count. (I will > grant I could be wrong on this, hence "probably".) > > 2) Artifically making a commodity rare, will cause a run on it before it's rare and push up the dates. > > > In order to provide something constructive, I think these policy proposals > attempt to bite off too much. Break it down into 3 separate ones. > > First, define events on the use curve. (BTW, it's logistic, not exponential) > Not only when we think we need to change policy, but why? Maybe we only > define one point in time for now, and just stay focused on what we need to > do to not get there. > > Next, define different policies that ARIN can use with regard to space > assignment. Whether you have a /16 or a IPv6 network might be the factors > that come up here, or whether it's a time based allocation -- you get a /16 > for 2 years then have to return it, or some other agreed-to space, if > you're asking for some swing space while you do something else. > > Last, tie the first event to policies. Once we approach that event in time, > we have a track record, and can discuss the next best policy to proceed > with. > > Discussing actions seperately from events, allows them to be fully discussed > with the ramifications, without getting into the side issues of when > things turn bad. Discussing the events allows a cleaner discussion of > growth, live data, models and expectations. Bringing it together last, > allows a discussion of what-when. > > If things are that rotten, then it may be that assignment policies change > now, even before the next event. > > > > On Fri, 11 May 2007, 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. >> >> >> Policy Proposal Name: IPv4 Soft Landing >> >> Author: David Conrad >> >> Proposal Version: 1.0 >> >> Submission Date: 2007-05-02 >> >> Proposal type: New >> >> Policy term: Permanent >> > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Mon May 14 15:54:09 2007 From: randy at psg.com (Randy Bush) Date: Mon, 14 May 2007 21:54:09 +0200 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <4648BBB1.5050700@bogomips.com> References: <464425E7.1070305@arin.net> <4648BBB1.5050700@bogomips.com> Message-ID: <4648BE61.7000703@psg.com> > If ARIN is going to do something to replace IPv4 with IPv6 this is in arin's charter? randy From Kavalec at BSWA.com Mon May 14 17:08:34 2007 From: Kavalec at BSWA.com (G. Waleed Kavalec) Date: Mon, 14 May 2007 15:08:34 -0600 Subject: [ppml] Policy Proposal: IPv4 Soft Landing Message-ID: -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Randy Bush > If ARIN is going to do something to replace IPv4 with IPv6 this is in arin's charter? randy _______________________________________________ Implicit, yes. No point being a registry of internet numbers if you don't have any more internet number. From jmorrison at bogomips.com Mon May 14 16:16:15 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Mon, 14 May 2007 13:16:15 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <4648BE61.7000703@psg.com> References: <464425E7.1070305@arin.net> <4648BBB1.5050700@bogomips.com> <4648BE61.7000703@psg.com> Message-ID: <4648C38F.9030305@bogomips.com> It certainly seems ARIN's articles of incorporation are worded broadly enough to do this: http://www.arin.net/about_us/corp_docs/artic_incorp.pdf Article 7 (6) "to promote and facilitate the expansion, development, and growth of the infrastructure of the internet for the general public and members by any means consistent with the public interest through other activities, including, but not limited to,..." I don't know if there are any amendments to this article, or what legal footing ARIN is with respect to taking an active stance in managing the transition. Randy Bush wrote: > > If ARIN is going to do something to replace IPv4 with IPv6 > > this is in arin's charter? > > randy > From bmanning at karoshi.com Mon May 14 16:32:20 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Mon, 14 May 2007 20:32:20 +0000 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: <20070514203220.GA24134@vacation.karoshi.com.> On Mon, May 14, 2007 at 03:08:34PM -0600, G. Waleed Kavalec wrote: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Randy Bush > > > > If ARIN is going to do something to replace IPv4 with IPv6 > > this is in arin's charter? > > randy > _______________________________________________ > > > Implicit, yes. > > No point being a registry of internet numbers > if you don't have any more internet number. except internet numbers are not commodities. they will not be consumed - the RIR system will still be needed to track who is using what resource. --bill From randy at psg.com Mon May 14 16:34:30 2007 From: randy at psg.com (Randy Bush) Date: Mon, 14 May 2007 22:34:30 +0200 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: <4648C7D6.6050303@psg.com> >> If ARIN is going to do something to replace IPv4 with IPv6 > this is in arin's charter? > Implicit, yes. > No point being a registry of internet numbers > if you don't have any more internet number. where does it say REPLACE ipv4, please? randy From Kavalec at BSWA.com Mon May 14 17:42:08 2007 From: Kavalec at BSWA.com (G. Waleed Kavalec) Date: Mon, 14 May 2007 15:42:08 -0600 Subject: [ppml] Policy Proposal: IPv4 Soft Landing Message-ID: ISP: Hey ARIN I need some new numbers. ARIN: Sorry ISP, we haven't REPLACED our stock. Like I said, it's implied. -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, May 14, 2007 2:35 PM To: G. Waleed Kavalec Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing >> If ARIN is going to do something to replace IPv4 with IPv6 > this is in arin's charter? > Implicit, yes. > No point being a registry of internet numbers > if you don't have any more internet number. where does it say REPLACE ipv4, please? randy From bmanning at karoshi.com Mon May 14 16:50:07 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Mon, 14 May 2007 20:50:07 +0000 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: <20070514205007.GB24337@vacation.karoshi.com.> On Mon, May 14, 2007 at 03:42:08PM -0600, G. Waleed Kavalec wrote: > ISP: Hey ARIN I need some new numbers. > ARIN: Sorry ISP, we haven't REPLACED our stock. perhaps you mean: ISP: Hey ARIN, I need some new numbers. ARIN: Sure, here you go. ISP: We dont like that style... what else do you have? ARIN: The other style is all checked out... however there are a few remnets... would you like some of those? neither ARIN, nor other RIR, nor IANA can create new IPv4 numbers. and conversly, they can not destroy them. ARIN can ensure that it tracks the density of use of the pool... some might think that such a task is clearly in its charter. --bill > > > Like I said, it's implied. > > > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Monday, May 14, 2007 2:35 PM > To: G. Waleed Kavalec > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > > >> If ARIN is going to do something to replace IPv4 with IPv6 > > this is in arin's charter? > > Implicit, yes. > > No point being a registry of internet numbers > > if you don't have any more internet number. > > where does it say REPLACE ipv4, please? > > randy > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From jmorrison at bogomips.com Mon May 14 17:16:59 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Mon, 14 May 2007 14:16:59 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: <4648D1CB.9000509@bogomips.com> It seems obvious, but maybe it shouldn't be an implicit assumption. Strictly speaking, IPv4 doesn't have to be replaced. It could run in parallel with IPv6 for ages. Maybe it will slowly wither away or maybe it'll be hacked to keep working. If ARIN intends to replace IPv4, it should say so in a policy. (If it's not, that's another matter). Eventually this will have to drive requirements, including dates to stop processing requests for new IPv4 addresses, administration, transfers etc. It may seem arbitrary to set a deadline, but a lot of software related decisions are like that. Microsoft could continue to support Windows 95 or legacy products forever, it's "arbitrary" in a sense that they could in theory support those systems forever, but they have business reasons for not doing so. If you're an ISP, you know from Cisco or Juniper when your router is end-of-life'd. You can buy support on it for a several years later (often at increasingly silly costs). At some point there's no support, no new warranties or software available for that hardware. The point is you know well in advance, you can stockpile spares and keep running or replace with new gear. Is ARIN going to support IPv4 forever? At some point they can not give out IP addresses, but they can deal with the transfers and other administration, collect (increasingly steep) fees and maybe delve into reclaiming unused address space etc. Is this the consensus? G. Waleed Kavalec wrote: > ISP: Hey ARIN I need some new numbers. > > ARIN: Sorry ISP, we haven't REPLACED our stock. > > > Like I said, it's implied. > > > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Monday, May 14, 2007 2:35 PM > To: G. Waleed Kavalec > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > > >>> If ARIN is going to do something to replace IPv4 with IPv6 >>> >> this is in arin's charter? >> Implicit, yes. >> No point being a registry of internet numbers >> if you don't have any more internet number. >> > > where does it say REPLACE ipv4, please? > > randy > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw+arin at tellme.com Mon May 14 17:59:22 2007 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 14 May 2007 14:59:22 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <4648D1CB.9000509@bogomips.com> References: <4648D1CB.9000509@bogomips.com> Message-ID: <20070514215922.GQ5379@shell01.corp.tellme.com> On Mon, May 14, 2007 at 02:16:59PM -0700, John Paul Morrison wrote: > If ARIN intends to replace IPv4, it should say so in a policy. Unless I have a horribly unclear understanding of what "stewardship" means, ARIN intends to manage number resources, I.e., IPv4, IPv6, and ASNs. ARIN is agnostic about what network protocol is used. It is, however, very interested in managing how the numbers are distributed. There's zero need for policy to state that we need to replace IPv4 with IPv6. Any replacement of IPv4 will be driven by the needs of the community, not by ARIN itself. -David From alh-ietf at tndh.net Mon May 14 18:24:47 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 14 May 2007 15:24:47 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> Message-ID: <06e601c79676$ae40ad10$0ac20730$@net> Rich Emmings wrote: > First, define events on the use curve. (BTW, it's logistic, not > exponential) Yes, but the scale is not limited to the IPv4 resource pool because the 'resource' is about enabled connectivity, not utilization of a particular header format. ----- <<---- 100's of devices / per person ~2050 --- / -- / - / -- / --- / -------- <<---- You are here in 2007 Please forgive the ascii art contortion of the logistic curve. From owen at delong.com Mon May 14 18:47:28 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 14 May 2007 15:47:28 -0700 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070514213631.GX73965@Space.Net> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> Message-ID: On May 14, 2007, at 2:36 PM, Gert Doering wrote: > Hi > > On Fri, May 11, 2007 at 06:58:55AM -0700, Owen DeLong wrote: >>> Do you think this should not be decided by an RFC, but rather as a >>> global >>> policy through each of the RIRs? >>> >> I am not sure. I kind of like Tony's (malformed) suggestion that >> ULA- >> C should >> come with PI. If the qualifications for ULA-C were the same, or, if >> ULA-C was >> only available to orgs. that had PI, I think that would be >> acceptable. > > I can't really understand the reasoning behind that. What are you > trying to achieve, why do you want to restrict handing out ULA-C to > only a specific (small) subset of folks out there? > I don't want to give ULA-C to people who have an incentive to abuse it as PI. > I'd take a much simpler approach - install a one-time setup fee, which > will prevent folks from just grabbing 10000s of ULA-C prefixes, and > then > just hand them out to whoever wants some (and pays the handling fee). > I specifically don't want to achieve the suggested objective and would strongly oppose such an action. > There's enough /48s in that /8 so that the risk of running out is > really low - if there is some mechanism to limit the amount of > prefixes > a single entity can request. Money works well for that, usually. > I don't care about running out. I care about less stringent standards in ULA criteria being used to create an end-run on PI policy. > [..] >> Not sure about that. I do support the idea of ULA-Central as >> intended, >> but, I'd have to see a policy or RFC that implemented it in such a >> way >> that I had reasonable confidence it wouldn't become "the easy way to >> get PI". If we're going to do that, I'd rather do it by relaxing the >> PI policy >> than by designating some "nudge nudge wink wink" address space. > > ULA-C becomes PI the moment folks will accept it in their routing > table > (and if that is a serious risk, ULA-L could as easily become PI the > same > way). But why should routing folks do that? > Hopefully routing folks won't, but, in my experience, $$$ can lead routing folks to ignore what should or shouldn't be done from an internet context and, instead, focus on what makes money. I agree that ULA-L is a bad idea for all the same reasons. However, there is nothing which can be done about ULA-L at the RIR policy level. At the RIR Policy level, ULA-C can be addressed, at least for the moment. > I, for one, hereby state that I will not route other folks ULA space > on AS5539. Period. > Good for you. If you can get everyone else with an AS to make the same promise in writing and make that promise binding on their successors and assigns, then, we might have something. Owen > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 113403 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From bmanning at karoshi.com Mon May 14 19:25:21 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Mon, 14 May 2007 23:25:21 +0000 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <4648D1CB.9000509@bogomips.com> References: <4648D1CB.9000509@bogomips.com> Message-ID: <20070514232521.GA25323@vacation.karoshi.com.> > Strictly speaking, IPv4 doesn't have to be replaced. It could run in > parallel with IPv6 for ages. Maybe it will slowly wither away or maybe > it'll be hacked to keep working. agreed. > Is ARIN going to support IPv4 forever? At some point they can not give > out IP addresses, but they can deal with the transfers and other > administration, collect (increasingly steep) fees and maybe delve into > reclaiming unused address space etc. from the ARIN mission statement: "Applying the principles of stewardship, ARIN, [elided], allocates Internet Protocol resources" and as long as IPv4 is considered an Internet Protocol resource, I expect ARIN would have an interest in it. --bill > > Is this the consensus? > > > G. Waleed Kavalec wrote: > >ISP: Hey ARIN I need some new numbers. > > > >ARIN: Sorry ISP, we haven't REPLACED our stock. > > > > > >Like I said, it's implied. > > > > > >-----Original Message----- > >From: Randy Bush [mailto:randy at psg.com] > >Sent: Monday, May 14, 2007 2:35 PM > >To: G. Waleed Kavalec > >Cc: ppml at arin.net > >Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > > > > > > >>>If ARIN is going to do something to replace IPv4 with IPv6 > >>> > >>this is in arin's charter? > >>Implicit, yes. > >>No point being a registry of internet numbers > >>if you don't have any more internet number. > >> > > > >where does it say REPLACE ipv4, please? > > > >randy > >_______________________________________________ > >This message sent to you through the ARIN Public Policy Mailing List > >(PPML at arin.net). > >Manage your mailing list subscription at: > >http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From BillD at cait.wustl.edu Mon May 14 19:31:55 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 14 May 2007 18:31:55 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing References: <464425E7.1070305@arin.net><4648BBB1.5050700@bogomips.com> <4648BE61.7000703@psg.com> <4648C38F.9030305@bogomips.com> Message-ID: I certainly think that ARIN's charter is consistent with the deployment of IPv6 addresses AND I think it can make efforts to educate the industry in their viewpoint on the matter and 'push' people toward the use of new(er) protocol numbers.... I see this similarly to that of 2 vs 4 byte ASNs issue and policy. All that can come to pass.....given that those who take such positions, make such proposals and that the industry finds consensus in those proposals. Then, if the minority is of the opinion that ARIN over-reaches, then they sue.... Seems to me that's the way of things in general. Bill Darte -----Original Message----- From: ppml-bounces at arin.net on behalf of John Paul Morrison Sent: Mon 5/14/2007 3:16 PM To: Randy Bush Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing It certainly seems ARIN's articles of incorporation are worded broadly enough to do this: http://www.arin.net/about_us/corp_docs/artic_incorp.pdf Article 7 (6) "to promote and facilitate the expansion, development, and growth of the infrastructure of the internet for the general public and members by any means consistent with the public interest through other activities, including, but not limited to,..." I don't know if there are any amendments to this article, or what legal footing ARIN is with respect to taking an active stance in managing the transition. Randy Bush wrote: > > If ARIN is going to do something to replace IPv4 with IPv6 > > this is in arin's charter? > > randy > _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmanning at karoshi.com Mon May 14 19:58:24 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Mon, 14 May 2007 23:58:24 +0000 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <06e601c79676$ae40ad10$0ac20730$@net> References: <464425E7.1070305@arin.net> <06e601c79676$ae40ad10$0ac20730$@net> Message-ID: <20070514235824.GB25323@vacation.karoshi.com.> On Mon, May 14, 2007 at 03:24:47PM -0700, Tony Hain wrote: > > Yes, but the scale is not limited to the IPv4 resource pool because the > 'resource' is about enabled connectivity, not utilization of a particular > header format. interesting point in the understanding curve. i'd posit that the blocks ARIN delegates stewardship of are done so because the delegee belives the delegation will be useful. (and today, useful is defined as community consensus on insertion into nearly everyones routing table...) It is NOT clear to me that in future, that the definition of a useful prefix is in its presumption of ubiquitious deployment in everyones routers. If this presumption is correct, there will need to be a fundamental shift in thinking. e.g. it will no longer be the community defining useful sized delegations, it will be the delegee and their upstreams (if any). Once and for all, the myth of "the global routing table" will be seen as such. IMHO of course. :) > > Please forgive the ascii art contortion of the logistic curve. we love the ascii art. perhaps IANA would hire you to do their ascii art? --bill From alh-ietf at tndh.net Mon May 14 20:28:42 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 14 May 2007 17:28:42 -0700 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> Message-ID: <071201c79687$fddbf2b0$f993d810$@net> Owen DeLong wrote: > ...... > > If you prefer the RIR process, would you be in favor of a global > > policy > > submitted to ARIN that had the provisions of the expired ULA-central > > draft, with the modification of removing "cental authority" and > > clearly > > designating how IANA should divide the space among the existing RIRs? > > > Not sure about that. I do support the idea of ULA-Central as intended, > but, I'd have to see a policy or RFC that implemented it in such a way > that I had reasonable confidence it wouldn't become "the easy way to > get PI". If we're going to do that, I'd rather do it by relaxing the > PI policy > than by designating some "nudge nudge wink wink" address space. The 'central authority' was not intended to preclude the RIR's, just not impose something upon them they didn't want. The RIR's are member organizations that don't sell or lease address space, they manage a resource on behalf of the members. If you want long term membership to grow and/or sustain the costs of running the organization, then you need to offer a service that is attractive. ULA-C space is an attractive resource to many organizations that have been burned on 1918 mergers. If you don't want that to become an alternate PI space, then recognize that PI space is another attractive resource that would justify sustaining membership. Most of the potential members that would be interested in one of those would also be interested in the other, so create a policy that automatically allocates both to reduce internal costs for interacting with the paperwork & database. The noise about PI blowing out the routing system is just that, -noise-. If all ~20k AS entities came and demanded PI space we would have a whopping 20k routing entries in the IPv6 DFZ BGP mesh. At 1/10th the IPv4 table, and basically stable vs. growing at a compound rate, that is not even noticeable. Tony From alh-ietf at tndh.net Mon May 14 20:28:47 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 14 May 2007 17:28:47 -0700 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070514053040.GA18747@vacation.karoshi.com.> References: <20070514053040.GA18747@vacation.karoshi.com.> Message-ID: <071301c79688$012662c0$03732840$@net> bmanning at karoshi.com wrote: > > ULA-central is NOT intended to be uses as IPv6 PI. > > but there is no way to stop it from becoming so. The only effective way to stop it is to make PI have a lower cost than ULA-C. The most straight forward way to implement that is; at the RIR policy level acknowledge that PI will exist and create the appropriate mechanisms to manage it; at the ISP level, recognize that PI is available and refuse (set exorbitant fees) to route ULA-C. Trying to stop something that is outside the RIR policy control through RIR policy is a waste of time and energy. Recognize that whatever you do PI will exist in some form, and avoid the situation where it is completely unmanageable by creating a formal process where it is easy enough to get that people won't bother with working around you. If you want something to be contained and managed then step up and manage it. Trying to abolish it will only ensure that it exists outside the realm of manageability. Tony From alh-ietf at tndh.net Mon May 14 20:42:47 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 14 May 2007 17:42:47 -0700 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070514213631.GX73965@Space.Net> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> Message-ID: <071d01c79689$f5f99910$e1eccb30$@net> Gert Doering wrote: > ... > I'd take a much simpler approach - install a one-time setup fee, which > will prevent folks from just grabbing 10000s of ULA-C prefixes, and then > just hand them out to whoever wants some (and pays the handling fee). A registration fee is a one-time event. RIR membership is ongoing and provides a way to know what is active. I doubt there would ever be need to reclaim/reuse any of the allocations, but this is an attractive resource, use it as such to provide a reason to be an RIR member. > ... > ULA-C becomes PI the moment folks will accept it in their routing table > (and if that is a serious risk, ULA-L could as easily become PI the same > way). But why should routing folks do that? PI will exist in whatever form it has to. If that means punching holes in PA space, then it will be that. Rather than trying to prevent the unpreventable through a disassociated policy, grab it and manage it. Create PI that is managed. If that exists in an easy to get form, the ULA-C discussion is moot because it will cost more to convince an ISP to route it than to just get recognized PI space. > > I, for one, hereby state that I will not route other folks ULA space > on AS5539. Period. > That is a fine position to take, but that is only one of ~20k AS's. Create a managed PI space, & ULA-C space, then the intended state will be easy for ISPs to enforce. Without both, unmanaged versions of both will be created and create confusion down the road. Tony From michael.dillon at bt.com Tue May 15 03:34:34 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 15 May 2007 08:34:34 +0100 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <20070514235824.GB25323@vacation.karoshi.com.> References: <464425E7.1070305@arin.net><06e601c79676$ae40ad10$0ac20730$@net> <20070514235824.GB25323@vacation.karoshi.com.> Message-ID: > (and today, useful is defined as community > consensus on insertion into nearly everyones routing table...) I don't think that has been true for a long time now. The consensus is that useful means that you can configure the addresses into a LAN and not worry about addressing conflicts in the future because the addresses are registered for your use and nobody else's. > e.g. it will > no longer be the community defining useful sized delegations, > it will be the delegee and their upstreams (if any). That is the way things stand today for large chunks of IPv4 space which many have noted, are missing from the global routing table views. --Michael Dillon From jordi.palet at consulintel.es Tue May 15 03:57:06 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 15 May 2007 09:57:06 +0200 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <071301c79688$012662c0$03732840$@net> Message-ID: And the only way to control ULA-central is to have it within the RIR system, instead of waiting for IETF to move ahead the document and doing themselves or thru and alternative third party organization. So having a "managed" path for ULA-central is in our hands. Regards, Jordi > De: Tony Hain > Responder a: > Fecha: Mon, 14 May 2007 17:28:47 -0700 > Para: , 'JORDI PALET MARTINEZ' > > CC: , > Asunto: RE: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs > NAT in arstechnica (seen on slashdot) > > bmanning at karoshi.com wrote: > >>> ULA-central is NOT intended to be uses as IPv6 PI. >> >> but there is no way to stop it from becoming so. > > The only effective way to stop it is to make PI have a lower cost than > ULA-C. The most straight forward way to implement that is; at the RIR policy > level acknowledge that PI will exist and create the appropriate mechanisms > to manage it; at the ISP level, recognize that PI is available and refuse > (set exorbitant fees) to route ULA-C. > > Trying to stop something that is outside the RIR policy control through RIR > policy is a waste of time and energy. Recognize that whatever you do PI will > exist in some form, and avoid the situation where it is completely > unmanageable by creating a formal process where it is easy enough to get > that people won't bother with working around you. If you want something to > be contained and managed then step up and manage it. Trying to abolish it > will only ensure that it exists outside the realm of manageability. > > Tony > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From Ed.Lewis at neustar.biz Mon May 14 14:16:13 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 14 May 2007 14:16:13 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464425E7.1070305@arin.net> References: <464425E7.1070305@arin.net> Message-ID: At 4:14 -0400 5/11/07, Member Services wrote: >Policy Proposal Name: IPv4 Soft Landing (Can't get the URL now, writing off-line.) I like this policy. At the RIPE meeting a chart was shown that of all space allocated, only 1-2% was PI. I know it is hard to judge what that statement means given the looseness of the statistic, so here is the URL of the presentation where it was presented. http://www.ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics.pdf See slide #10. I asked what the number at ARIN was and was given a preliminary approximation of about the same value. I.e., from this is seems that PI is nothing compared to PA when it comes to draining v4. That is, if I understand the statistic. Maybe it has too many steps. I'm sure that can be sanded down. I think the auditing cost ought to remain on the LIR/ISP as this is their request for space. I assume that this isn't retroactive. I like that this ties events to the remaining pool and not to a calendar. I would like this to be a global policy (i.e., headed for IANA), if the global policy process would take too long then there there is a problem with that process. Now for my soapbox...what's good about this is that it forces ISP's into the realization that they can either stay v4 and stop *growing* when numbers run out or they have to switch to something with a bigger address space (v6 is the one alternative at hand) and continue to be able grow customers. This is growth, not sustain-ability (my spell checking isn't good off-line). If an ISP does not want new customers, they don't have to move to v6. 'Course, over time what doesn't grow usually withers. No one is forced to go to v6, it's a choice of to grow or not. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From plzak at arin.net Tue May 15 05:15:24 2007 From: plzak at arin.net (Ray Plzak) Date: Tue, 15 May 2007 05:15:24 -0400 Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: <20070515083942.GA73965@Space.Net> References: <46484947.6090702@zurich.ibm.com> <20070515083942.GA73965@Space.Net> Message-ID: The US DoC has as much say for ARIN as it does for the RIPE NCC. The RIRs existed before ICANN. The relationship between the RIRs and ICANN is defined in the ASO MoU, an agreement between ICANN on the one hand and the NRO on behalf of the RIRs on the other. There is no mention in the ICANN bylaws of the RIRs. Ray > -----Original Message----- > From: Gert Doering [mailto:gert at space.net] > Sent: Tuesday, May 15, 2007 4:40 AM > To: Dean Anderson > Cc: ppml at arin.net; address-policy-wg at ripe.net; > jordi.palet at consulintel.es; ietf at ietf.org > Subject: Re: [address-policy-wg] Re: Can the RIRs bypass the IETF and > do their own thing? > > Hi, > > On Mon, May 14, 2007 at 03:04:19PM -0400, Dean Anderson wrote: > [..] > > ICANN can end the MoU at any time, and find a new technical > consultant. > > The IETF can also end the MoU at any time. But the IETF doesn't have > the > > authority to appoint a new IANA operator. > [..] > > The RIR's can do whatever ICANN and the US Government allow them to > do. > > The IETF _can_ be taken out of the picture if there is cause to do > so. > > Not quite. If ICANN decides "we won't listen to IETF anymore", or "we > try to inforce non-useful politics to the RIRs" there is no big reason > why the RIRs couldn't just kick ICANN, install the NRO in its place, > and > change the structure to > > IETF -> NRO -> RIRs > > Remember: the existing mechanism works, because the communities (!!) > agree > that it's a useful way to handle address distribution. > > The US DoC might have some say for ARIN, but the rest of the world > couldn't care less - and I'm sure that the DoC is well aware of this > and > won't try to break apart working structures. > > So this is all sort of academic. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 113403 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf From michael.dillon at bt.com Tue May 15 05:30:17 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 15 May 2007 10:30:17 +0100 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> Message-ID: > Now for my soapbox...what's good about this is that it forces ISP's > into the realization that they can either stay v4 and stop *growing* > when numbers run out or they have to switch to something with a > bigger address space (v6 is the one alternative at hand) and continue > to be able grow customers. This is not an appropriate goal for ARIN policy. I will vote against any policy that attempts to PUNISH or FORCE organizations to do something or other. That entire approach is inconsistent with ARIN's nature as a cooperative association of organizations who use Internet numbering resources. If you want to force ISPs into realizing something then the appropriate tools are public relations, press releases and so forth. Not policy changes. --Michael Dillon From bmanning at karoshi.com Tue May 15 05:34:48 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 15 May 2007 09:34:48 +0000 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46485649.6090408@netability.ie> References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> Message-ID: <20070515093448.GA28881@vacation.karoshi.com.> On Mon, May 14, 2007 at 01:30:01PM +0100, Nick Hilliard wrote: > bmanning at karoshi.com wrote: > >>ULA-central is NOT intended to be uses as IPv6 PI. > > > > but there is no way to stop it from becoming so. > > Other than by issuing bogon lists, where the ULA-centra prefixes will be > noted. You certainly can't stop it or any other type of ipv6 address > from becoming PI. But you can stop it from being useful PI space, which > is all you need to do. > > Nick you, my friend, have an over inflated view of your ability to effect "useful" for others. imho of course. --bill From bmanning at karoshi.com Tue May 15 06:05:35 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 15 May 2007 10:05:35 +0000 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <464981B0.2040303@inex.ie> References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> <20070515093448.GA28881@vacation.karoshi.com.> <464981B0.2040303@inex.ie> Message-ID: <20070515100535.GB28881@vacation.karoshi.com.> On Tue, May 15, 2007 at 10:47:28AM +0100, Nick Hilliard wrote: > bmanning at karoshi.com wrote: > >On Mon, May 14, 2007 at 01:30:01PM +0100, Nick Hilliard wrote: > >>Other than by issuing bogon lists, where the ULA-centra prefixes will > >>be noted. You certainly can't stop it or any other type of ipv6 > >>address from becoming PI. But you can stop it from being useful PI > >>space, which is all you need to do. > >> > >>Nick > > > > you, my friend, have an over inflated view of your ability > > to effect "useful" for others. imho of course. > > I make no claim of any such ability :-) er... perhaps I misread. you stated; "you can stop it from being useful PI space, which is all you need to do." i understand this as you (party Q) being able to effect any communications between myself (party R) and Gert (party S)... the single time this is effective is when party Q is in the transit path btwn R & S. > > The point is, if a block is carved out and marked specifically as being > non-routable on the public v6 internet, it will have degraded > connectivity to some degree or other. do i care? does that effect the usefulness of a given prefix if some ISP someplace filters out (refuses to listen) to the announcements? i posit that: a) i have zero influence on your operational behaviour when i have zero business relationship w/ you b) you have the ability to set whatever policies you like for packet acceptance into your network and packet egress from your network. > > On a related issue, I'd be interested to know what the reachability > degradation was like for the last of the 3ffe:: space after 6/6/6? You > didn't happen to do any measurements on it? for those parties still using the space, it is useful. i suspect that parties who filter prefixes "degrade" their clients ability to reach nodes/content in those filtered ranges. of course some clients utilize other tools (VPNs, tunnels, etc) to bypass crippled ISP thinking. (from the POV of the client ... kind of like many hotel networks) your general qustion (prefix reachability) is based on (imho again) a flawed premise... if i may, could you clarify the two endpoints for such a reachability study? > > Nick, > psychically effecting usefulness all over the v6 internet got me there... can you also bend spoons w/ your mental powers? :) --bill From bmanning at karoshi.com Tue May 15 06:20:36 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 15 May 2007 10:20:36 +0000 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <20070514235824.GB25323@vacation.karoshi.com.> Message-ID: <20070515102036.GC28881@vacation.karoshi.com.> On Tue, May 15, 2007 at 08:34:34AM +0100, michael.dillon at bt.com wrote: > > (and today, useful is defined as community > > consensus on insertion into nearly everyones routing table...) > > I don't think that has been true for a long time now. The consensus is > that useful means that you can configure the addresses into a LAN and > not worry about addressing conflicts in the future because the addresses > are registered for your use and nobody else's. hum... can you tell me the rational for minimum prefix size policies then? those certainly are community generated consenus opinions. uniqueness is certainly important, but being forced into a /21 when I really only need a /28 talks to something other than uniquness. > > e.g. it will > > no longer be the community defining useful sized delegations, > > it will be the delegee and their upstreams (if any). > > That is the way things stand today for large chunks of IPv4 space which > many have noted, are missing from the global routing table views. such may be true in legacy (pre-RIR) ranges. i posit that it will become increasingly true for the entire IPv4 range. --bill > > --Michael Dillon From heldal at eml.cc Tue May 15 06:30:03 2007 From: heldal at eml.cc (Per Heldal) Date: Tue, 15 May 2007 12:30:03 +0200 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070514053040.GA18747@vacation.karoshi.com.> References: <20070514053040.GA18747@vacation.karoshi.com.> Message-ID: <1179225003.4778.19.camel@localhost.localdomain> On Mon, 2007-05-14 at 05:30 +0000, bmanning at karoshi.com wrote: > > > > ULA-central is NOT intended to be uses as IPv6 PI. > > but there is no way to stop it from becoming so. What makes that different from any other randomly selected block of addresses if you don't apply some form of filter? The current routing-architecture applied to v6 will blow up in our face sooner or later without improved mechanisms to prevent excessive de-aggregation and unauthorised use of unallocated blocks. I'm no fan of private addressing, but it doesn't seem awfully hard to include the handling of ULA-central in such a solution. //per From ringley at us.ibm.com Tue May 15 08:03:21 2007 From: ringley at us.ibm.com (Gale Ringley) Date: Tue, 15 May 2007 08:03:21 -0400 Subject: [ppml] Steve Ringley is out of the office. Message-ID: I will be out of the office starting 05/13/2007 and will not return until 05/21/2007. I am on vacation and will return on May 21st 2007. For Network Services project issues please contact Angel Rivera at +1 (614) 481-1279. For Cisco VPN or WMS Network issues please contact Kevin Morris at +1 (219) 695-2434. For other immediate assistance needs please open a ticket with the NiSource Help Desk at +1 (877) 357-3911. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kavalec at BSWA.com Tue May 15 11:24:58 2007 From: Kavalec at BSWA.com (G. Waleed Kavalec) Date: Tue, 15 May 2007 09:24:58 -0600 Subject: [ppml] Policy Proposal: IPv4 Soft Landing Message-ID: -----Original Message----- > Now for my soapbox...what's good about this is that it forces ISP's > into the realization that they can either stay v4 and stop *growing* > when numbers run out or they have to switch to something with a > bigger address space (v6 is the one alternative at hand) and continue > to be able grow customers. This is not an appropriate goal for ARIN policy. I will vote against any policy that attempts to PUNISH or FORCE organizations to do something or other. -------------------- The point as I read it... "forces ISP's into the realization" ...really talks about educating not punishing. Though a dash of cold water in the face like this may blur the edges. From dean at av8.com Tue May 15 12:46:22 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 15 May 2007 12:46:22 -0400 (EDT) Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: Message-ID: On Tue, 15 May 2007, Ray Plzak wrote: > The US DoC has as much say for ARIN as it does for the RIPE NCC. The US DoC, through IANA functions, says, e.g., what IP Address blocks each can allocate. That seems to qualify as 'much say' You seem to be confusing delegation of authority with loss of authority. The DoC has contracted the IANA function to ICANN and doesn't involve itself much, and ultimately plans to get out altogether. However, the IANA operator (ICANN) then has 'much say'. But the DoC 'get out altogether' event hasn't happened yet. So you can't write out the DoC just yet. > The RIRs existed before ICANN. The relationship between the RIRs and > ICANN is defined in the ASO MoU, an agreement between ICANN on the one > hand and the NRO on behalf of the RIRs on the other. There is no > mention in the ICANN bylaws of the RIRs. The fallacy of this claim was already stated: RIRs get their authority and IP Address Allocations, etc from IANA. The fact that RIRs existed before ICANN is irrelevant, because IANA existed before the RIRs. And, as I noted, IANA functions are now contracted to ICANN. Technically, it is in fact the IANA (not ICANN) that has direct control over RIRs. But, as I pointed out, ICANN has full control over IANA functions by contract with the US Government. And, as I pointed out, the IETF is a technical consultant to ICANN. The MoUs are just that: Memoranda of Understanding. MoUs can be terminated, and don't supercede the contracts with the US Government. So, it is possible for ICANN/IANA to disregard the technical advice of its technical consultant and so it is possible for ICANN/IANA to allow the RIRs to do something which the IETF doesn't approve. There is nothing the IETF can do about it. The IETF can't fire ICANN as IANA operator, but ICANN could fire the IETF as its technical consultant. Of course, the IETF can also quit as the technical consultant. The IETF has no exclusive monopoly on technical experts. The practical effect of a break with the IETF is to get rid of only the people in the IESG and IAB. Roughly ~25 experts are easily replaced. BTW, it is not the case that I think any of this _will_ happen, but it clarifies the relationships to know what is possible under the current contracts. I expect that people will reach reasonable accomodations with all the stakeholders involved. Of course, sometimes that doesn't happen. But, probably people are more reasonable when they realize the consequences of unreasonable intransigence. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From andy at nosignal.org Tue May 15 12:52:03 2007 From: andy at nosignal.org (Andy Davidson) Date: Tue, 15 May 2007 17:52:03 +0100 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <20070514205007.GB24337@vacation.karoshi.com.> References: <20070514205007.GB24337@vacation.karoshi.com.> Message-ID: On 14 May 2007, at 21:50, bmanning at karoshi.com wrote: > neither ARIN, nor other RIR, nor IANA can create new IPv4 numbers. > and conversly, they can not destroy them. ARIN can ensure that > it tracks the density of use of the pool... some might think that > such a task is clearly in its charter. Go easy on me, I can't find my tin hat ... but does this mean it's time to drag up a new thread about reclaiming 'legacy' /8s (IANA reserved ones, military, squeezing down 44/8 into something a bit smaller, etc.,etc.) -a From plzak at arin.net Tue May 15 13:22:59 2007 From: plzak at arin.net (Ray Plzak) Date: Tue, 15 May 2007 13:22:59 -0400 Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: > > > The US DoC has as much say for ARIN as it does for the RIPE NCC. > > The US DoC, through IANA functions, says, e.g., what IP Address blocks > each can allocate. That seems to qualify as 'much say' > Didn't say how much say, just said that whatever say it had for ARIN it was the same as it had for the RIPE NCC. > You seem to be confusing delegation of authority with loss of > authority. > The DoC has contracted the IANA function to ICANN and doesn't involve > itself much, and ultimately plans to get out altogether. However, the > IANA operator (ICANN) then has 'much say'. But the DoC 'get out > altogether' event hasn't happened yet. So you can't write out the DoC > just yet. > Don't how you arrived at that conclusion based on a casual observation. Not writing them out, don't know how you got that. > > The RIRs existed before ICANN. The relationship between the RIRs and > > ICANN is defined in the ASO MoU, an agreement between ICANN on the > one > > hand and the NRO on behalf of the RIRs on the other. There is no > > mention in the ICANN bylaws of the RIRs. > > The fallacy of this claim was already stated: What is false about those statements? RIRs get their authority > and IP Address Allocations, etc from IANA. The fact that RIRs existed > before ICANN is irrelevant, because IANA existed before the RIRs. And, > as I noted, IANA functions are now contracted to ICANN. Technically, it > is in fact the IANA (not ICANN) that has direct control over RIRs. But, > as I pointed out, ICANN has full control over IANA functions by > contract > with the US Government. And, as I pointed out, the IETF is a technical > consultant to ICANN. The MoUs are just that: Memoranda of > Understanding. > MoUs can be terminated, and don't supercede the contracts with the US > Government. > Never intimated anything about authority lines or derivation of authority, just pointing out some of the factors in the relationship between ICANN and the RIRs. Ray From paul at vix.com Tue May 15 13:37:32 2007 From: paul at vix.com (Paul Vixie) Date: Tue, 15 May 2007 17:37:32 +0000 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Your message of "Tue, 15 May 2007 07:24:42 GMT." <4649603A.3020100@CC.UniVie.ac.at> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <071201c79687$fddbf2b0$f993d810$@net> <4649603A.3020100@CC.UniVie.ac.at> Message-ID: <42029.1179250652@sa.vix.com> > I am prepared to start listening again as soon as the "Gain"-figures in the > CIDR report start to change dramatically: > > --- 11May07 --- > ASnum NetsNow NetsAggr NetGain % Gain Description > Table 217147 140280 76867 35.4% All ASes i pretty much hate TE routes. companies who build their business plans on TE routes are, as randy bush once called it, just grazing in the commons. but apparently nobody filters on prefix length any more. that surprises me. From cliffb at cjbsys.bdb.com Tue May 15 13:38:09 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Tue, 15 May 2007 13:38:09 -0400 Subject: [ppml] getting converts to V6 Message-ID: <4649F001.9020607@cjbsys.bdb.com> I am a latecomer to this group but have been on the internet since 1990 or so and have a single grandfathered Class C address. I see a lot of ideas proposed to get v4 extended and v6 started. Most seem hard or convoluted to implement. Right now I have a no fee grandfathered Class C and it will probably do me until I retire. To do anything with V6, I'd have to get involved with lots of paperwork and fees. I have absolutely no incentive to go to v6. On the other hand, I'd like to work with v6 just to get it working and understand it. If there is really a desire to get v6 started, ARIN should give every entity that has existing IPv4 addresses equivalent IPv6 addresses under whatever provisions they are under now, including no fees for grandfathered PI addresses like mine. The rationale is as follows. Most of the early adopters (not covered by ARIN) were moderately technical and are most likely to start using v6 but have no incentive to do so. Giving them the equivalent privileges in v6 without all the agreements and paperwork would eliminate any reason for not giving v6 a try. It may upset some but maybe the early adopters should get a break just for being early adopters. Certainly if they want to expand beyond what they have grandfathered, they should come under the new rules. You're going to trade off giving some people something for free against the probability that they will be more likely to start using v6 to get things rolling. If I got IPv6 addresses, it would give me leverage to get my upstream ISP to route IPv6. Once they start, it will get easier and easier to get v6 going. Getting IPv6 going is something like running a yard sale. You're not in it to make money, you're in it to get rid of stuff (in this case unused IPv6 addresses) If you run a yard sale with things priced too high, you just end up dragging a lot of stuff back to the basement. If you price them really low, you won't have to carry them back to the basement and you'll end up with a lot more money than you'd have from not selling all the stuff you priced too high. Is it fair to everyone? Maybe not. Will it work? Who knows? What would you lose? A few of the ridiculously large number of IPv6 addresses that aren't being used anyhow. But the odds favor getting at least some additional IPv6 addresses working. IPv6 is at the same point income taxes were at the start of WWII. The government wanted to start withholding taxes in advance but couldn't figure out how to do that without whacking people twice with taxes during the starting year. Someone proposed the idea of forgiving the taxes for the year prior and just start collecting the withholding on Jan 1 and go forward. People were convinced that the government would go broke but in fact that didn't happen since they started collecting the current year taxes immediately rather than get a lump sum 16 months later and we've happily(?) paid monthly withholding ever since and haven't complained about taxes nearly as much since we never see the money in our pocket in the first place. We need something like that giveaway to get IPv6 started. Having painted a somewhat rosy picture of what could happen, I am also reminded of the great GOSIP fiasco of the early 90's where the US government was directed to start actively using OSI which was supposed to offer all(most of?) the options that v6 is supposed to offer. That of course died a horrible death. Since v4 is running out, there is more incentive to make v6 work but people will need much more incentive than I've seen offered so far or they will just get more and more clever about stretching out v4. I'm sure I have oversimplified some of this, but I thought I'd offer the viewpoint of a newcomer/outsider to the group as to what I think needs to be done to get v6 going. Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From jeroen at unfix.org Tue May 15 14:02:35 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 15 May 2007 19:02:35 +0100 Subject: [ppml] getting converts to V6 In-Reply-To: <4649F001.9020607@cjbsys.bdb.com> References: <4649F001.9020607@cjbsys.bdb.com> Message-ID: <4649F5BB.7070306@spaghetti.zurich.ibm.com> Cliff Bedore wrote: [..] > Right now I have a no fee grandfathered Class C and it will probably do > me until I retire. 'No fee'? You don't pay for electricity, hardware, transit and a plethora of other things that are actually required to use those numbers? Can you please explain where that is, as there are some large companies who are really interested in that kind of free stuff. > To do anything with V6, I'd have to get involved > with lots of paperwork and fees. I have absolutely no incentive to go > to v6. On the other hand, I'd like to work with v6 just to get it > working and understand it. If you want 'free address space', try one of the many IPv6 Tunnel Brokers if you want it for free. They will provide you with a /48 of address space for you to play with. It won't be PI though, and they are paying for electricity etc for you. Another way: 2002::::/48 or actually as you have a /24: 2002::::/40 > Is it fair to everyone? Maybe not. Will it work? Who knows? What > would you lose? A few of the ridiculously large number of IPv6 > addresses that aren't being used anyhow. But the odds favor getting at > least some additional IPv6 addresses working. Address space should be distributed based on NEED. When you can JUSTIFY your need for a /32 or a /48, you have actual users who are using it. When you have users, you also have somebody/thing that pays the small fee to the various registries for having the privilege of your own chunk of address space. Greets, Jeroen (Next up: free 12 digit phone numbers, because I had a 4 digit phone number for free too!) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes De