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 Desc: OpenPGP digital signature URL: From dogwallah at gmail.com Tue May 15 14:02:33 2007 From: dogwallah at gmail.com (McTim) Date: Tue, 15 May 2007 21:02:33 +0300 Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: On 5/15/07, Dean Anderson wrote: > > 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' AFAIK, DoC has nothing to do with which /8's go to which RIR, I doubt they could if they wanted to. -- Cheers, McTim $ whois -h whois.afrinic.net mctim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at unfix.org Tue May 15 14:05:44 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 15 May 2007 19:05:44 +0100 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <4649F1E4.1080806@CC.UniVie.ac.at> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <071201c79687$fddbf2b0$f993d810$@net> <4649603A.3020100@CC.UniVie.ac.at> <42029.1179250652@sa.vix.com> <4649F1E4.1080806@CC.UniVie.ac.at> Message-ID: <4649F678.80903@spaghetti.zurich.ibm.com> Wilfried Woeber, UniVie/ACOnet wrote: [..] > I simply take it as living proof that almost nobody really cares about seeing > some (50..)70K+ routes more or less in their boxes, these days. See it is a business trick: when there are say 300k routes in the routing tables, you are forcing your competition to also carry that amount of routes in their tables, that means your competition will also have to buy fast new cool routers with a lot of memory. This makes various vendors happy, but it also takes care of emptying your competitions pocket books. When they spend all their cash on routers, they won't be able to invest in other things or need to up their prices, resulting in those customers coming to you etc etc etc. Economics 101. Has not much to do with "The Internet" any more. The road to monopoly has many routes ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Tue May 15 14:09:25 2007 From: randy at psg.com (Randy Bush) Date: Tue, 15 May 2007 08:09:25 -1000 Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: <4649F755.4000301@psg.com> how far down a phony power struggle and pissing contest are folk going to let jordi drag this group while trying to get policy passed based on an unpublished internet-draft? randy From stephen at sprunk.org Tue May 15 14:19:16 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 15 May 2007 13:19:16 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing References: <20070514205007.GB24337@vacation.karoshi.com.> Message-ID: <009b01c7971d$9768ebf0$463816ac@atlanta.polycom.com> Thus spake "Andy Davidson" > 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.) There is a proposal under discussion in this very forum about reclamation. However, that proposal does not affect legacy space, and counsel is still trying to sort out what, if any, power ARIN has over legacy holders who haven't signed an RSA. IANA could release some historically reserved space such as 0/8 and 1/8 to the RIRs, and there's a side discussion about opening up 240/4, however IANA expects the IETF to publish an RFC on such things first, there's usually good reasons for blocks staying reserved, and they'd only extend the life of v4 a few months. It's like trying to keep the Titanic from sinking by bailing water with a thimble. 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 Lee at Dilkie.com Tue May 15 14:25:14 2007 From: Lee at Dilkie.com (Lee Dilkie) Date: Tue, 15 May 2007 14:25:14 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <4649F5BB.7070306@spaghetti.zurich.ibm.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> Message-ID: <4649FB0A.6030304@Dilkie.com> Jeroen Massar wrote: > 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. > I think he means "free" as in "no ridiculous fees to ARIN". > > 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 > > Interesting.. That's the attitude of the many data carriers back in the late 70s and early 80's. I worked on X.25 networks (and ISDN too), designing and building switching gear. Contrast that with the early internet where there were a lot of "free" access points ("free" means I paid for my access costs but nothing else). I remember those days very well because *we* were the datacomm experts and how dare those long haired hippies, with their tcp and ip, try and muscle in our *own* rightful business... Well, here we are. There's hardly a legacy data network left. The practice of attracting networking experts with "free" access to the new networks did work very well indeed. Cliff is right. You want to attract those early adopters. I also am one, with my own grandfathered Class C (okay, /24) and I'm in the same boat. I *am* playing with IPv6 but via one of those tunnel brokers but it's hardly serious. Giving me a v6 PI space for free would certainly make me want to find a provider that could route v6 to me natively. Then all sorts of interesting things might happen. I can also see you throw the "justify" and "need" words about. The plain truth is this.. You "need" to move people over to IPv6. They are not going to go willingly unless you can offset the cost. The "need" is *yours*, not theirs. The cost should also be *yours*. (and lets be honest, there is no real cost to assigning a number). -lee From steve at blighty.com Tue May 15 14:30:52 2007 From: steve at blighty.com (Steve Atkins) Date: Tue, 15 May 2007 11:30:52 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <4649FB0A.6030304@Dilkie.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> Message-ID: <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> On May 15, 2007, at 11:25 AM, Lee Dilkie wrote: > > Cliff is right. You want to attract those early adopters. I also am > one, > with my own grandfathered Class C (okay, /24) and I'm in the same > boat. > I *am* playing with IPv6 but via one of those tunnel brokers but it's > hardly serious. Giving me a v6 PI space for free would certainly > make me > want to find a provider that could route v6 to me natively. Then all > sorts of interesting things might happen. Arguably, those with grandfathered class Cs who haven't needed any more network space since they got them are those who are least likely to do anything interesting with IPv6. They're not early adopters. They're people who used to be early adopters a long time ago. > I can also see you throw the "justify" and "need" words about. The > plain > truth is this.. You "need" to move people over to IPv6. They are not > going to go willingly unless you can offset the cost. The "need" is > *yours*, not theirs. The cost should also be *yours*. (and lets be > honest, there is no real cost to assigning a number). Yup. Cheers, Steve From james at towardex.com Tue May 15 14:38:46 2007 From: james at towardex.com (James Jun) Date: Tue, 15 May 2007 14:38:46 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <4649FB0A.6030304@Dilkie.com> References: <4649F001.9020607@cjbsys.bdb.com><4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> Message-ID: <00f801c79720$45d4f380$1efc5dd8@HCMC.local> Lee, Actually, with current standing ARIN policy, IPv6 fees are waived (though I'm not sure if they are going to start charging next year). You still have to justify on basis of /48 PI or /32 PI dependent upon your needs and network routing topology, but for the moment to my knowledge there are no fees -- as long as you are either ARIN member or IPv4 subscriber which automatically holds membership. Regards, James > > Jeroen Massar wrote: > > 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. > > > I think he means "free" as in "no ridiculous fees to ARIN". > > > > 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 > > > > > Interesting.. That's the attitude of the many data carriers back in the > late 70s and early 80's. I worked on X.25 networks (and ISDN too), > designing and building switching gear. Contrast that with the early > internet where there were a lot of "free" access points ("free" means I > paid for my access costs but nothing else). > > I remember those days very well because *we* were the datacomm experts > and how dare those long haired hippies, with their tcp and ip, try and > muscle in our *own* rightful business... Well, here we are. There's > hardly a legacy data network left. The practice of attracting networking > experts with "free" access to the new networks did work very well indeed. > > Cliff is right. You want to attract those early adopters. I also am one, > with my own grandfathered Class C (okay, /24) and I'm in the same boat. > I *am* playing with IPv6 but via one of those tunnel brokers but it's > hardly serious. Giving me a v6 PI space for free would certainly make me > want to find a provider that could route v6 to me natively. Then all > sorts of interesting things might happen. > > I can also see you throw the "justify" and "need" words about. The plain > truth is this.. You "need" to move people over to IPv6. They are not > going to go willingly unless you can offset the cost. The "need" is > *yours*, not theirs. The cost should also be *yours*. (and lets be > honest, there is no real cost to assigning a number). > > -lee > From jmorrison at bogomips.com Tue May 15 14:04:38 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Tue, 15 May 2007 11:04:38 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> Message-ID: <4649F636.4030701@bogomips.com> Any policy could be sugar-coated to keep most people happy. Many large, deep-pocketed organizations already have the technical expertise to implement IPv6, and are already implementing real networks or software products. Governments are starting to mandate IPv6 support. Software and hardware obsolescence is a fact of life. Good companies manage this process so that customers can plan for change. I agree that public relations, conferences and other lobbying is needed to build some consensus on whether to plan for an IPv4 end of life date. Obviously ARIN can not pick an arbitrary date that 90% or even 50% of people object to. This is no different than Microsoft announcing end of support on a version of Windows, then back-tracking when there's been customer outcry. There's uncertainty in not creating an end-of-life date an. When are we going to run out of addresses? How will we transition? Businesses don't like uncertainty, and while Telcos and ISPs have of money invested in current networks, they're going to have to upgrade them in 5 or 10 years anyway to keep up with growth, adding an IPv4 deadline is something the engineers understand and the managers can factor in to their business case. michael.dillon at bt.com wrote: >> 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 > > _______________________________________________ > 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 Lee at Dilkie.com Tue May 15 15:11:14 2007 From: Lee at Dilkie.com (Lee Dilkie) Date: Tue, 15 May 2007 15:11:14 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> Message-ID: <464A05D2.3080309@Dilkie.com> Steve Atkins wrote: > On May 15, 2007, at 11:25 AM, Lee Dilkie wrote: > > >> Cliff is right. You want to attract those early adopters. I also am >> one, >> with my own grandfathered Class C (okay, /24) and I'm in the same >> boat. >> I *am* playing with IPv6 but via one of those tunnel brokers but it's >> hardly serious. Giving me a v6 PI space for free would certainly >> make me >> want to find a provider that could route v6 to me natively. Then all >> sorts of interesting things might happen. >> > > Arguably, those with grandfathered class Cs who haven't needed any > more network space since they got them are those who are least likely > to do anything interesting with IPv6. They're not early adopters. > They're > people who used to be early adopters a long time ago. > > Hmmm. So because I didn't become an ISP and get into the internet big time to make money. Because I concentrated on network security research and data protocols and had no need for more than my initial allocation. For those reasons you can consider me unworthy of IPv6 space as an early adopter. wow. That's like telling Burt Rutan (http://www.scaled.com/) that he can't design any more airplanes (and spaceplanes) because he never grew his operation to the size of Boeing or Airbus. The fact that the man's company has made advances in aerodynamics and flight materials that have been and are being adopted by every manufacturer is of no interest to you? I'm sorry. ISPs don't actually invent anything. Invention of new things is done by others. Creating new demand is done by others. ISPs, like broadcasters, record companies, film companies, are in the business of distributing the ideas of others, not inventing their own. ISPs will *never*, by themselves, make the IPv6 move you so desire. (it'll probably be either gaming industry or, what else, porn) I'd like to point out that IPv4 is still going to be required for a long time for all the existing, legacy, applications. Even if you move to IPv6, you'll still need an IPv4 address because dual-stack is the *only* workable transition mechanism. What some "early adopter" might do, however, is come up with a brand new, compelling, application that is IPv6 pure. *That* is what you folks need to happen. And who knows from what quarter it will come... Cheers, -lee From bmanning at karoshi.com Tue May 15 15:29:00 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 15 May 2007 19:29:00 +0000 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46499DBD.6080301@inex.ie> References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> <20070515093448.GA28881@vacation.karoshi.com.> <464981B0.2040303@inex.ie> <20070515100535.GB28881@vacation.karoshi.com.> <46499DBD.6080301@inex.ie> Message-ID: <20070515192900.GA32430@vacation.karoshi.com.> On Tue, May 15, 2007 at 12:47:09PM +0100, Nick Hilliard wrote: > bmanning at karoshi.com wrote: > > 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. > > "you" == RIRs/whoever publishing these blocks in a list of prefixes which > should not be seen on the public ipv6 internet, due to community mandate. i have problems w/ the term "public [I,i]nternet" - could you please define it? > - do you want to base your bilateral communications and possibly your > business on an something which is frankly unsupported as designed and > could stop working at any stage if operator Q were to implement > uncontroversial prefix filters? are you suggesting that party Q is the only option for communications btwn parties R & S? > - do you want to go beyond communications between R and S? sure... > Prove the point, Bill. Go ahead and advertise 10/8 and use it in anger on > the public ipv4 internet. When you've got some good figures which > indicate how useful it is, let us know. not a chance. i will note that there are a whole bunch of folks who do use 10.0.0.0/8 "in anger" on the internet - i see many packets w/ this netblock as a source address. > >>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? > > Given your position on announcing 3ffe::/24 and 3ffe:800::/24 until fairly > recently, evidently not :-) marked by whom? (and wrt 3ffe:: space... folks are still using it and so i still annouce it. it remains useful for them. :) > > 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. > > No argument there. But we're talking about different things. So far, > you're talking about connectivity between exactly two specific parties. > I'm not. so your talking about multicast? last i checked, nearly all traffic was unicast; e.g. end to end, e.g. between exactly two specific parties. > > >>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? > > > > 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? > > I was thinking more of X = time, Y = % of ipv6 space reachable from > ${3ffe}, where 100% at a particular timepoint would be # of reachable > prefixes from some place known to be relatively well connected (cue flames > for fuzzy specification). Given your reaction to the question, it sounds > like you haven't done looked into this, which is a minor pity. but that is the wrong question. how in the world do you ensure reachability across thousands of ASNs, each of which is willing/able to set their own policies about prefix acceptance? I'm almost persuaded that I don't WANT reachability to all that v6 space... too many places to hid spambots. (and yes, the fuzzy specification is hard to code to... :) > Nick, > bill's friend(tm) thats a new one... :) care to take out a partnership in "Bills Bait & Sushi" ... there are franchise ops available. From bmanning at karoshi.com Tue May 15 15:37:29 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 15 May 2007 19:37:29 +0000 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <20070514205007.GB24337@vacation.karoshi.com.> Message-ID: <20070515193729.GB32430@vacation.karoshi.com.> On Tue, May 15, 2007 at 05:52:03PM +0100, Andy Davidson wrote: > > 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 for one, I am not happy w/ the existant policy proposal on reclaiming space. i think it would be more useful to find a way to incent legacy address holders to establish a relationship with ARIN (or relevent RIR) without trying to browbeat them into submission. such an outcome ought to be less about "reclaimation" and more about accountability. it would be reasonable to consider that since ARIN has the charter to be stewards of IP numbers (generally speaking) it would be ideal if ARIN could get agreements in place w/ the holders of IP numbers that received them pre-ARIN. .... at least as a first step. do you agree? --bill From jeroen at unfix.org Tue May 15 15:58:42 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 15 May 2007 20:58:42 +0100 Subject: [ppml] getting converts to V6 In-Reply-To: <464A05D2.3080309@Dilkie.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> Message-ID: <464A10F2.9070408@spaghetti.zurich.ibm.com> Lee Dilkie wrote: [..] > Hmmm. So because I didn't become an ISP and get into the internet big > time to make money. Because I concentrated on network security research > and data protocols and had no need for more than my initial allocation. "The world is unfair, when you are longer in the business you earned more money". Sorrym but that doesn't work as an argument in any business. Unfortunately, unlike in a computer game, not everybody starts out at the same time. Then again, if you play WoW you probably also hate those level 2000 VulcanDreadWarLocks or whatever they play there as they where older and have more money and can buy a Dragon to play with. Now if you are totally against the fees for registration. Then voice that. Write a proposal and submit it. Don't say that you can't get IPv6 address space, as especially in ARIN land that is totally untrue: PA and PI are available, and as some others pointed out, if you have IPv4 or membership fees are already being waved. If there is anybody who should be complaining then it is all those people who didn't get a private "free" /24 (Class C in your old style parlance) to play with at home with their single laptop and are now restricted to an ISP who is NATting them together with the rest of the city. > For those reasons you can consider me unworthy of IPv6 space as an early > adopter. Early adopter? Even I can't call myself an early adopter. Early adopters had IPv6 address space in 1996 from the 6bone project, something in the 5xxx::/16 range (hmm I did use that from SURFnet through somebody else who had a tunnel there though ;). After 1998 you got a /24 (just like Bill Manning is still using now that ep.net returned to the net). If you participated in the 6bone you where an early adopter. And getting that address space was: !FREE! It has also been deprecated since last year and only one person, see above, is still using it. Currently if you want IPv6 address space you can: - Go to a RIR and request a /48 PI - Go to a LIR and request a /48 out of their PA - Use 2002::::/48, - Use ULA's Loads of options, oh and the one I mentioned before: Tunnel Brokers. Just ask the registries (or check the RIR data) if they can count how much address space a certain TB has made available to end-users, for free might I add. And note that that is not the only provider of that kind of address space, there are a few others, quality might vary though from what I have heard. > wow. That's like telling Burt Rutan[..] What does aerospace have to do with IP Addresses? Anyway, if you want to 'design' stuff, you can use ULA's for that, they just won't route on the global internet. Also see above for other ways to get 'free' address space. [..] > I'd like to point out that IPv4 [..] because dual-stack is the *only* > workable transition mechanism. Everybody knows that, the IETF has designed IPv6 and the large amount of IPv6 Transition Mechanisms around it. Anybody who says something else drank too much cool aid ;) Greets, Jeroen (who, together with Pim, most likely still holds the record for most inet6nums's in the RIPEdb, so please don't say you can't get IPv6 address space for free, as that is B******T! Thanks again to all the participating ISP's for providing the address space to endusers for free and with the great quality connectivity that they provide along with it!) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Tue May 15 19:30:59 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 16 May 2007 00:30:59 +0100 Subject: [ppml] getting converts to V6 In-Reply-To: <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> Message-ID: <464A42B3.201@spaghetti.zurich.ibm.com> William Herrin wrote: [..] > When I was an undergrad way back before the bubble, I filled out a > trivial form with no payments or prerequisites and got a class C > assignment for the private network I shared with two other students in > our apartment. Let me put that in current time and applying it to IPv6, as clearly you can't read what I wrote in my previous messages: I filled in no forms, and got from various places several THOUSAND of /48's for free: 30x /40 to be exact at current time. Or to count them a bit: 7680 /48's or 503.316.480 /64's. And you claim you can't get a single /48!? Strange... Do also note that those come including free transit et all provided by really good quality ISP's who make sure that the backbone stays running. This being made available for free to a LOT of people over the last 5+ years already, who have been doing a lot of experimentation and use already. To put it more in your perspective, I am still only a postgrad, and that only since last year. So these nice experiments of old time are still possible, I have been doing them for the last 7 years already, ever since I was an undergrad. It actually has become much easier. Just sign up with one of the various Tunnel Broker systems out there and get your own publicly routeable address space. No, indeed it is not PI, no you can't do BGP. But is that what you where talking about? If you need BGP, you most likely have two upstreams, if you have that you also need some routers and other hardware to really make it useable, and not forget transit costs. If you are able to cover those you are playing with the big boys already. Times change, it is different now. If you want a toy chunk space of Internet, contact one of the various organizations around the Internet that can provide you with such a chunk so that you can play with it. There are also organizations that provide you with BGP if you really want it. When you are doing real business or simply want to play with the big boys, and in that case you can easily pay the small fee that is attached to it. Greets, Jeroen And if you still haven't figured out that I am writing about SixXS, here is the link: http://www.sixxs.net which is, as you can read from the About page, just a privately conducted development of software which grew a teeny weeny tiny bit out of hand. For the other projects, Google is your friend, they are out there. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From michael.dillon at bt.com Wed May 16 05:38:11 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 May 2007 10:38:11 +0100 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' So it seems that you and Ray are in agreement. All the other details are not terribly relevant to RIR policy discussions because we have processes and structures to make sure that everything is done properly. We have no plans to change any of the structures because at the present time, they seem to work OK. As for the matter that started this, central ULAs, there is not need to worry about who controls what. The fact is that it is customary for new address types to be defined *FIRST* in the IETF and even if there is the possibility of an alternate process, we would not dream of exercising that unless the customary process, via the IETF, had broken down. The IETF process cannot be considered broken just because a draft has expired. In fact, expiry of a draft indicates that the original authors no longer care enough about the matter to progress it further. The WG chair of IPv6 Operations has already offered the v6ops list http://www.ietf.org/html.charters/v6ops-charter.html For those people who *DO* wish to progress a draft for Central ULA addresses. This is a sign that the IETF process is open for business in this case. At this point, I think it is inappropriate to continue the Central ULA discussion on the RIR policy lists. In fact, if any policy were to come out of such a discussion, I would vote against it even though my company could potentially benefit from something like a Central ULA address block. But at the same time, my company supports the IETF process in general and I don't believe we would want to be perceived as usurping the IETF. That is why I would vote against any policy proposal that is not based on an RFC. I urge all of you who have an interest in Central ULA addresses, both pro and con, to take your discussion to the v6ops list. And I urge the people in favour of Central ULA addresses to write an Internet draft explaining just what it is that you want to do. At this point in time, there is no valid draft document so I don't even know what it is that you are discussing. --Michael Dillon From michael.dillon at bt.com Wed May 16 05:59:31 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 May 2007 10:59:31 +0100 Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? Message-ID: Was: To: ietf at ietf.org; ppml at arin.net; address-policy-wg at ripe.net > > 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' So it seems that you and Ray are in agreement. All the other details are not terribly relevant to RIR policy discussions because we have processes and structures to make sure that everything is done properly. We have no plans to change any of the structures because at the present time, they seem to work OK. As for the matter that started this, central ULAs, there is not need to worry about who controls what. The fact is that it is customary for new address types to be defined *FIRST* in the IETF and even if there is the possibility of an alternate process, we would not dream of exercising that unless the customary process, via the IETF, had broken down. The IETF process cannot be considered broken just because a draft has expired. In fact, expiry of a draft indicates that the original authors no longer care enough about the matter to progress it further. The WG chair of IPv6 Operations has already offered the v6ops list http://www.ietf.org/html.charters/v6ops-charter.html For those people who *DO* wish to progress a draft for Central ULA addresses. This is a sign that the IETF process is open for business in this case. At this point, I think it is inappropriate to continue the Central ULA discussion on the RIR policy lists. In fact, if any policy were to come out of such a discussion, I would vote against it even though my company could potentially benefit from something like a Central ULA address block. But at the same time, my company supports the IETF process in general and I don't believe we would want to be perceived as usurping the IETF. That is why I would vote against any policy proposal that is not based on an RFC. I urge all of you who have an interest in Central ULA addresses, both pro and con, to take your discussion to the v6ops list. And I urge the people in favour of Central ULA addresses to write an Internet draft explaining just what it is that you want to do. At this point in time, there is no valid draft document so I don't even know what it is that you are discussing. --Michael Dillon From jordi.palet at consulintel.es Wed May 16 06:21:03 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2007 12:21:03 +0200 Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: Message-ID: Michael, If you know about the IETF process, you will also know that the proper venue for ULA-central ID discussion is ipv6 at ietf.org. The draft belongs to there and the original authors are working in a new submission (as I already indicated in other RIRs mail exploders). If you care about the details of that document, discussion should take care there (ipv6 at ietf.org). This doesn't precludes on discussion in parallel the related policy (proposal), in those RIR service regions where it has been submitted (not yet here at ARIN, but I will do soon). Regards, Jordi > De: > Responder a: > Fecha: Wed, 16 May 2007 10:59:31 +0100 > Para: > Conversaci?n: [address-policy-wg] Re: Can the RIRs bypass the IETF and do > their own thing? > Asunto: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do > their own thing? > > Was: To: ietf at ietf.org; ppml at arin.net; address-policy-wg at ripe.net > >>> 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' > > So it seems that you and Ray are in agreement. All the other details are > not terribly relevant to RIR policy discussions because we have > processes > and structures to make sure that everything is done properly. We have no > plans to change any of the structures because at the present time, they > seem to work OK. > > As for the matter that started this, central ULAs, there is not need to > worry about who controls what. The fact is that it is customary for new > address types to be defined *FIRST* in the IETF and even if there is the > possibility of an alternate process, we would not dream of exercising > that > unless the customary process, via the IETF, had broken down. > > The IETF process cannot be considered broken just because a draft has > expired. In fact, expiry of a draft indicates that the original authors > no > longer care enough about the matter to progress it further. The WG chair > of IPv6 Operations has already offered the v6ops list > http://www.ietf.org/html.charters/v6ops-charter.html > For those people who *DO* wish to progress a draft for Central ULA > addresses. This is a sign that the IETF process is open for business in > this case. > > At this point, I think it is inappropriate to continue the Central ULA > discussion on the RIR policy lists. In fact, if any policy were to come > out of such a discussion, I would vote against it even though my company > could potentially benefit from something like a Central ULA address > block. > But at the same time, my company supports the IETF process in general > and > I don't believe we would want to be perceived as usurping the IETF. That > is why I would vote against any policy proposal that is not based on an > RFC. > > I urge all of you who have an interest in Central ULA addresses, both > pro > and con, to take your discussion to the v6ops list. And I urge the > people > in favour of Central ULA addresses to write an Internet draft explaining > just what it is that you want to do. At this point in time, there is no > valid draft document so I don't even know what it is that you are > discussing. > > --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 michael.dillon at bt.com Wed May 16 06:36:39 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 May 2007 11:36:39 +0100 Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: > If you know about the IETF process, you will also know that the proper > venue > for ULA-central ID discussion is ipv6 at ietf.org. Then why are you dragging it into the RIR policy groups? Fred Baker has offered the v6ops working group, which again, is an IETF venue, not an RIR policy list. > This doesn't precludes on discussion in parallel the related policy > (proposal), in those RIR service regions where it has been submitted (not > yet here at ARIN, but I will do soon). As you have pointed out, there is no draft under discussion so any talk in the RIRs is beyond premature. I would hope that the Advisory Council rejects your proposal on that basis. There is absolutely no urgency to act upon Central ULA addressing until after it reaches RFC status. We should wait. --Michael Dillon From jordi.palet at consulintel.es Wed May 16 06:52:46 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2007 12:52:46 +0200 Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: Message-ID: I've not started the discussion of ULA-central on this list. It has been started in other RIRs because they had accepted my policy proposals on that. Discussing about the ID and the policy proposals are different issues, and can be handled in parallel, unless you show me anything in the PDP that says "no". Regards, Jordi > De: > Responder a: > Fecha: Wed, 16 May 2007 11:36:39 +0100 > Para: > Conversaci?n: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and > do their own thing? > Asunto: Re: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do > their own thing? > >> If you know about the IETF process, you will also know that the proper >> venue >> for ULA-central ID discussion is ipv6 at ietf.org. > > Then why are you dragging it into the RIR policy groups? Fred Baker has > offered the v6ops working group, which again, is an IETF venue, not an > RIR policy list. > >> This doesn't precludes on discussion in parallel the related policy >> (proposal), in those RIR service regions where it has been submitted > (not >> yet here at ARIN, but I will do soon). > > As you have pointed out, there is no draft under discussion so any talk > in the RIRs is beyond premature. > > I would hope that the Advisory Council rejects your proposal on that > basis. There is absolutely no urgency to act upon Central ULA addressing > until after it reaches RFC status. We should wait. > > --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 bicknell at ufp.org Wed May 16 08:58:04 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 16 May 2007 08:58:04 -0400 Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: <4649F755.4000301@psg.com> References: <4649F755.4000301@psg.com> Message-ID: <20070516125804.GB95772@ussenterprise.ufp.org> In a message written on Tue, May 15, 2007 at 08:09:25AM -1000, Randy Bush wrote: > how far down a phony power struggle and pissing contest are folk going to > let jordi drag this group while trying to get policy passed based on an > unpublished internet-draft? It's not a power struggle, it's a power vacuum. The IVTF has been consumed by internal politics that have resulted in a process that produces standards that are a dollar short and a day late. The "V" in the IVTF like this as it allows them to set proprietary standards and reap the economic benefits. Just look at cases like how long it took the IETF to come up with something like VRRP, Cisco had HSRP in 1987, and the IETF took another 10 years to release a VRRP standard in 1998. 10 years is an entire boom and bust cycle to this industry, one which the IETF has a great track record of missing. In the case of IPv6 the IETF failed to produce any addressing guidelines that worked in the real world. They seem to have ignored 30 years of history, thrown the baby out and kept the bath water, and are now surprised that everyone is unhappy. I can't point to a single group involved with IPv6 who thinks we've done the right thing so far, it's rather impressive when you can make everyone unhappy. I think ULA-Central is a terrible band-aid that completely ignores the real problem once again; that we need a designed in way to connect disparate networks without hitting a numbering conflict every single time as we do with RFC 1918 space. Rather than address that problem during the design phase, the IETF came up with some half brained ideas that are difficult and costly to implement, and have huge side effects. However, I do believe if people want a "ULA-Central" type service, and they want it today the RIR process is the only way to get it. It's quite clear to me, and I think everyone else that the IETF is going to provide no additional useful input prior to the real world deployment of IPv6 on a wide scale. The IETF has built us a boat. The front half is an aircraft carrier, the back half is a wooden sailing vessel. There are plenty of life preservers on board, but they are all infant sized. They have stocked coal in the bunker to fuel the nuclear reactor, and put cured meat in the state of the art refrigerator. They even suggested we get Gilligan as a Captain, since he has experience with exactly how we'll end up. No surprise some of us on shore looking at the vessel we're about to ride in are trying to buy a satellite phone and an inflatable dinghy before we shove off. Perhaps rather than attacking those who are merely trying to keep from drowning, your harsh words would be better used on the IETF who put us in this position. -- 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 heather.schiller at verizonbusiness.com Mon May 14 14:28:31 2007 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Mon, 14 May 2007 18:28:31 +0000 (GMT) Subject: [ppml] help with the acronyms? In-Reply-To: <17992.40899.677781.454559@lucifer.wonderworks.com> References: <17992.40899.677781.454559@lucifer.wonderworks.com> Message-ID: On Mon, 14 May 2007, Kyle Jones wrote: > Is there a glossary somewhere that explains ULA, RIR, NRO, ASO, > MoU, etc? I don't know of a glossary (maybe someone can put one up on the ARIN site?) ULA - Unique Local Address (google ULA central IPv6) RIR - Regional Internet Registry (ARIN, RIPE, APNIC, LACNIC, AFRINIC) NRO - Number Resource Organization (http://www.nro.net/) ASO - Address Supporting Organization (http://aso.icann.org/) MoU - Memorandum of Understanding - Memorandum of Understanding is a document of agreement between 2 organizations. Without knowing the context, it may be the agreement between the US Dept of Commerce and ICANN Lee Howard once made a slide, that showed the relationship between various organizations, registries, and Advisory councils. I don't think I have a copy of it though. --Heather > _______________________________________________ > 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 heather.schiller at verizonbusiness.com Tue May 15 14:55:37 2007 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Tue, 15 May 2007 18:55:37 +0000 (GMT) Subject: [ppml] getting converts to V6 In-Reply-To: <4649F001.9020607@cjbsys.bdb.com> References: <4649F001.9020607@cjbsys.bdb.com> Message-ID: On Tue, 15 May 2007, Cliff Bedore wrote: > 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 Paperwork and fees from whom? The ARIN fees for IPv6 address space are currently waived. The form to obtain v6 space from ARIN is rather simple, and probably wouldn't take more than a couple of minutes for an enduser. Same for the RSA and billing paperwork. > 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. > Who's to say that existing v4 holders need or want an equivalent amount of space in v6? Alot of existing v4 holders are defunct, why give them v6 space? Having folks come back to get v6 space serves other purposes as well: you have to re-validate your contact information, sign an RSA agreement, and it allows ARIN to provide stats on how much v6 space is being handed out over time. Just handing out blocks to isn't very good stewardship - and while v6 is plentiful, managing it well from the outset is still a good idea. > > 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. This assumes that most of the early adopters are still around.. and I think that you would find that a lot of folks aren't still around. Some of the v6 early adopters are the same.. but some never held a legacy block. > Giving them the equivalent privileges > in v6 without all the agreements and paperwork would eliminate any > reason for not giving v6 a try. Are you averse to paperwork? the RSA agreement? or that ARIN could revoke your assignment? I don't think it would be popular at all, don't even know if it would be possible, that is if ARIN's legal dept would allow it, for resources to be handed out without an RSA agreement. >It may upset some but maybe the early > adopters should get a break just for being early adopters. Certainly if They are - early adopters of v6 space are currently not being charged fees for the space. > 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. > Have you asked your upstream to assign you IPv6 space? There is an argument here to be made about heirarchical assignment of address space for route aggregation. (I point you to all the data about route table growth, particularly with the addition of IPv6 routes) You've already noted that you probably could continue using your existing v4 block for a long time, which sounds to me like you don't have a business case for prodding your provider into providing v6 transit. > > 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. > Last I checked ARIN was a non-profit (different from a not for profit, btw) and their goal isn't to make money - but to be good stewards in the distribution and management of a finite resource. > > 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. > I agree that new ideas and discussion on advancing v6 deployment should happen - and the more people that talk about it, that think about it the better. > > > 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/ > > > > > _______________________________________________ > 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 heather.schiller at verizonbusiness.com Tue May 15 15:11:36 2007 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Tue, 15 May 2007 19:11:36 +0000 (GMT) Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <4649F678.80903@spaghetti.zurich.ibm.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <071201c79687$fddbf2b0$f993d810$@net> <4649603A.3020100@CC.UniVie.ac.at> <42029.1179250652@sa.vix.com> <4649F1E4.1080806@CC.UniVie.ac.at> <4649F678.80903@spaghetti.zurich.ibm.com> Message-ID: On Tue, 15 May 2007, Jeroen Massar wrote: > Wilfried Woeber, UniVie/ACOnet wrote: > [..] >> I simply take it as living proof that almost nobody really cares about seeing >> some (50..)70K+ routes more or less in their boxes, these days. > > See it is a business trick: when there are say 300k routes in the > routing tables, you are forcing your competition to also carry that > amount of routes in their tables, that means your competition will also I'm going to assume by "300k routes in the routing tables" that you are referring to the 'global internet routing table'. Well remember there are 2 routing tables, the 'global internet routing table' and a providers internal routing table.. You aggregate where you can and don't send internal routes to peers, only PI and routes that get leaked for multihoming/traffic engineering reasons. The larger the provider and the more fragmented their address space, the larger their internal routing table. So by the time the 'global internet routing table' reaches 300k routes, your largest transit providers will be well past 300k. > have to buy fast new cool routers with a lot of memory. This makes Does this go for folks who think PI is great too? I'd be happy to deggregate to everyone, and get this over with right now.. but something tells me that wouldn't last more than a few hours. I'm not interested in making the competition have to buy hardware too -- unless it pushes the vendors along to build new hardware. I just want a vendor to make something that can support all the routes and not have to replace it by the time we get it deployed. > various vendors happy, but it also takes care of emptying your > competitions pocket books. When they spend all their cash on routers, > they won't be able to invest in other things or need to up their prices, > resulting in those customers coming to you etc etc etc. Economics 101. > Has not much to do with "The Internet" any more. > > The road to monopoly has many routes ;) > > Greets, > Jeroen > > ############################################### # Heather Schiller # # Customer Security & IP Address Management # # 800.900.0241 # # security at mci.com # ############################################### From owen at delong.com Wed May 16 10:52:42 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2007 07:52:42 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: References: <4649F001.9020607@cjbsys.bdb.com> Message-ID: <6E031F28-0427-483D-AF14-957D04A3A60A@delong.com> >> 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 > > Paperwork and fees from whom? > > The ARIN fees for IPv6 address space are currently waived. The > form to > obtain v6 space from ARIN is rather simple, and probably wouldn't take > more than a couple of minutes for an enduser. Same for the RSA and > billing paperwork. I keep hearing this refrain, but, it simply isn't true. The ARIN maintenance fees for IPv6 are waived for _MEMBERS_ . However, for non-members, the fees are NOT waived. Also, the INITIAL fees are NOT waived. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From martin.hannigan at batelnet.bs Wed May 16 12:13:27 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Wed, 16 May 2007 12:13:27 -0400 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) Message-ID: <464b2da7.373.825.29903@batelnet.bs> ----- Original Message ----- From: Jeroen Massar To: Woeber at CC.UniVie.ac.at Cc: ppml at arin.net, address-policy-wg at ripe.net Subject: Re: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) Date: Tue, 15 May 2007 19:05:44 +0100 > Wilfried Woeber, UniVie/ACOnet wrote: > [..] > > I simply take it as living proof that almost nobody > > really cares about seeing some (50..)70K+ routes more or > less in their boxes, these days. > > See it is a business trick: when there are say 300k routes > in the routing tables, you are forcing your competition to > also carry that amount of routes in their tables, that > means your competition will also have to buy fast new cool > routers with a lot of memory. This makes various vendors > happy, but it also takes care of emptying your > competitions pocket books. When they spend all their cash > on routers, they won't be able to invest in other things > or need to up their prices, resulting in those customers > coming to you etc etc etc. Economics 101. Has not much to > do with "The Internet" any more. > > The road to monopoly has many routes ;) The hyperbole is so thick that it can be cut with a chainsaw. -M< From jeroen at unfix.org Wed May 16 11:25:10 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 16 May 2007 16:25:10 +0100 Subject: [ppml] getting converts to V6 In-Reply-To: <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com><3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> Message-ID: <464B2256.4020101@spaghetti.zurich.ibm.com> [somebody wrote off-list, replying on-list, bcc'd to the replyer] > $2400 per year is not a small fee. It is $200 per month. > Add 2 T1's to that and you get $1500/Month. > That is more than a house man, just to run BGP and be ISP independent. You pay <1500/month for a house? Which place is that? That is what you pay for a single room over here. Strange pricing, I think you are being ripped off for a T1 @ $650/month. To put it in another way, you are paying $1300*12 = $15600/year for IP but can't pay $2400 for the actual addresses!? And forgetting all about the factors like hardware, power, humans involved etc. Skewed world. > That's a big expense just to be ISP independent. It is indeed a huge privilege to be ISP independent. It takes a lot of knowledge and investment of various things to do it correctly. If you are incapable of doing that, then please don't. There are enough unmanaged networks on the Internet already and really another couple of them is something to avoid. > ARIN's frugle policy is killing the Internet off for all but the rich. > ARIN's annual budget is 10 million dollars, the fat cats need to just give > out the rest of the Ips already so we can move on to the next stage of the > Internet. They are a not for profit organization. As such they don't make a profit. If you don't like the billing schemes, then create a proposal and submit it, get people to vote for it and it will be passed. You will be able to get IP addresses for 'free' and they will for sure all be gone soon enough, with a lot of other people coming a bit later complaining about it. Of course they would still have to justify that address space before they get it. > By dragging out IPV4 you are only damaging the Internet by driving the price > of IP space to the moon. When oil runs out, what happens to the price of oil? Now repeat the same question for IPv4 space. (That is if you actually are so stupid to pay for it to somebody else when ARIN asks only a mere $1500/year) > The way they are doing it now in 5 years a single class C will go for > $100,000 dollars on the IP black market. Better hold on to your /24 then. (It's /24, Classes where deprecated in 1993, which is already 14 years ago, see RFC1519) Clearly, if it is going to be worth 100k, then your feeble $200/month to ARIN is nothing now is it. Better invest on time ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From heather.schiller at verizonbusiness.com Wed May 16 11:39:32 2007 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Wed, 16 May 2007 15:39:32 +0000 (GMT) Subject: [ppml] getting converts to V6 In-Reply-To: <464B2256.4020101@spaghetti.zurich.ibm.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> Message-ID: On Wed, 16 May 2007, Jeroen Massar wrote: > [somebody wrote off-list, replying on-list, bcc'd to the replyer] > >> $2400 per year is not a small fee. It is $200 per month. >> Add 2 T1's to that and you get $1500/Month. >> That is more than a house man, just to run BGP and be ISP independent. > > You pay <1500/month for a house? Which place is that? > That is what you pay for a single room over here. > > Strange pricing, I think you are being ripped off for a T1 @ $650/month. > To put it in another way, you are paying $1300*12 = $15600/year for IP > but can't pay $2400 for the actual addresses!? And forgetting all about > the factors like hardware, power, humans involved etc. Skewed world. > >> That's a big expense just to be ISP independent. > > It is indeed a huge privilege to be ISP independent. It takes a lot of > knowledge and investment of various things to do it correctly. > If you are incapable of doing that, then please don't. There are enough > unmanaged networks on the Internet already and really another couple of > them is something to avoid. > >> ARIN's frugle policy is killing the Internet off for all but the rich. >> ARIN's annual budget is 10 million dollars, the fat cats need to just give >> out the rest of the Ips already so we can move on to the next stage of the >> Internet. > > They are a not for profit organization. As such they don't make a profit. > > If you don't like the billing schemes, then create a proposal and submit > it, get people to vote for it and it will be passed. You will be able to > get IP addresses for 'free' and they will for sure all be gone soon > enough, with a lot of other people coming a bit later complaining about > it. Of course they would still have to justify that address space before > they get it. I'm sure someone else will jump in here and say this too -- but billing fees aren't set by policy proposal and aren't set by the community/membership. I think that would be the board.. (and if it is, well, members are the folks who vote for 'em) > >> By dragging out IPV4 you are only damaging the Internet by driving the price >> of IP space to the moon. > > When oil runs out, what happens to the price of oil? Now repeat the same > question for IPv4 space. (That is if you actually are so stupid to pay > for it to somebody else when ARIN asks only a mere $1500/year) > >> The way they are doing it now in 5 years a single class C will go for >> $100,000 dollars on the IP black market. > > Better hold on to your /24 then. (It's /24, Classes where deprecated in > 1993, which is already 14 years ago, see RFC1519) > > Clearly, if it is going to be worth 100k, then your feeble $200/month to > ARIN is nothing now is it. Better invest on time ;) > > Greets, > Jeroen > > From BillD at cait.wustl.edu Wed May 16 11:38:40 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 16 May 2007 10:38:40 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <4649F001.9020607@cjbsys.bdb.com> Message-ID: > It may upset some but maybe the early adopters should get a > break just for being early adopters. Yup...you've had a free ride and are still getting a free ride administratively from ARIN and to think that privelege should entitle you to more free privelege seems removed from reality. Bill Darte ARIN AC > > > > 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/ > > > > > _______________________________________________ > 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 Wed May 16 11:59:49 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2007 08:59:49 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <464B2256.4020101@spaghetti.zurich.ibm.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com><3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> Message-ID: <6C9A0BC1-73FF-4F66-8369-B87781CE8167@delong.com> On May 16, 2007, at 8:25 AM, Jeroen Massar wrote: > [somebody wrote off-list, replying on-list, bcc'd to the replyer] > >> $2400 per year is not a small fee. It is $200 per month. >> Add 2 T1's to that and you get $1500/Month. >> That is more than a house man, just to run BGP and be ISP >> independent. > It's also not an accurate reflection of the IPv6 end-user fees. Currently, you only need to pay $500 initially per assignment. Then, your annual maintenance fees are $100 per year for _ALL_ ARIN resources. So, if you already have an ASN or IPv4 space, your additional cost per year is $0. If you're an ISP, then, theoretically, you have customers paying you for your services and $1,500 per month divided by the 200 customers you plan to have within a year works out to less than $8/customer. > You pay <1500/month for a house? Which place is that? > That is what you pay for a single room over here. > Yep... Same here. > Strange pricing, I think you are being ripped off for a T1 @ $650/ > month. > To put it in another way, you are paying $1300*12 = $15600/year for IP > but can't pay $2400 for the actual addresses!? And forgetting all > about > the factors like hardware, power, humans involved etc. Skewed world. > >> That's a big expense just to be ISP independent. That's about what circuit+service costs for T1 run these days. If you've got a better deal, contact me off list. I could use a cheap T1 to back up my DSL. > It is indeed a huge privilege to be ISP independent. It takes a lot of > knowledge and investment of various things to do it correctly. > If you are incapable of doing that, then please don't. There are > enough > unmanaged networks on the Internet already and really another > couple of > them is something to avoid. > It's not a privilege, but, it does take knowledge, effort, and equipment. I won't dignify the monetization rants in either direction. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From BillD at cait.wustl.edu Wed May 16 13:23:26 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 16 May 2007 12:23:26 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <3c3e3fca0705161008o3695f645j457b719ac32e8b52@mail.gmail.com> Message-ID: Small danger that IPv6 will not emerge if it is the best option for those wishing to communicate in the future. I am in favor of support for v6 and have supported the waiver of fees. I have been vocal in support of PI v6 space as I believe end users should not be penalize for a failing routing protocol. IPv6 has been emerging for 10 years and IPv4 has been dwindling for the same amount of time. What remedy is it to give legacy holders another legacy block and have them outside of the system the industry endorses as the means to provide fair and professional oversight to Internet number resources? Let them step up, apply for space and get it. Should we pay them to take it, pay them to use it? bd > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf > Of William Herrin > Sent: Wednesday, May 16, 2007 12:08 PM > To: Bill Darte > Cc: PPML at arin.net > Subject: Re: [ppml] getting converts to V6 > > > On 5/16/07, Bill Darte wrote: > > Yup...you've had a free ride and are still getting a free ride > > administratively from ARIN and to think that privelege > should entitle > > you to more free privelege seems removed from reality. > > Bill, > > That's what the objections to automatically assigning v6 > space to all current v4 holders boil down to. The legacy v4 > holders didn't pay their fair share of the ARIN boards' plane > tickets to Puerto Rico. During the transition to IPv6 you > want to correct this "mistake." > > IPv4 space is running out and IPv6 is not on track to wide > deployment prior to that crunch. Is it good judgement to > pursue a trifling inequity in the face of a looming crisis? > > If being unfair helps get IPv6 deployed to ubiquity, DO IT. > > Regards, > Bill Herrin > > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > From BillD at cait.wustl.edu Wed May 16 13:28:10 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 16 May 2007 12:28:10 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <3c3e3fca0705161008o3695f645j457b719ac32e8b52@mail.gmail.com> Message-ID: Oh, and by the way... You seem to feel strongly about such an ARIN policy, perhaps you should propose it. I or any other AC member would be happy to help you craft the proposal and ensure that it wide distribution for possible consensus. bd > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf > Of William Herrin > Sent: Wednesday, May 16, 2007 12:08 PM > To: Bill Darte > Cc: PPML at arin.net > Subject: Re: [ppml] getting converts to V6 > > > On 5/16/07, Bill Darte wrote: > > Yup...you've had a free ride and are still getting a free ride > > administratively from ARIN and to think that privelege > should entitle > > you to more free privelege seems removed from reality. > > Bill, > > That's what the objections to automatically assigning v6 > space to all current v4 holders boil down to. The legacy v4 > holders didn't pay their fair share of the ARIN boards' plane > tickets to Puerto Rico. During the transition to IPv6 you > want to correct this "mistake." > > IPv4 space is running out and IPv6 is not on track to wide > deployment prior to that crunch. Is it good judgement to > pursue a trifling inequity in the face of a looming crisis? > > If being unfair helps get IPv6 deployed to ubiquity, DO IT. > > Regards, > Bill Herrin > > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > From JOHN at egh.com Wed May 16 13:42:28 2007 From: JOHN at egh.com (John Santos) Date: Wed, 16 May 2007 13:42:28 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: Message-ID: <1070516133342.917B-100000@Ives.egh.com> I have no problem with the current policy. I have my class C and don't need any more. However, you people do seem to have a problem and want to force us little guys into selling our souls to some big ISP, except we don't get anything from this, instead we have to pay through the nose. How much does it actually cost to maintain a single record, a few hundred bytes of information that never changes? As best I can tell, you would want to charge me several hundred dollars a year, close to a dollar per address, whereas large ISPs get addresses for a fraction of a penny per year. You guys want people to jump on the IPv6 bandwagon. You really want them to jump on the money wagon. Not bloody likely. On Wed, 16 May 2007, Bill Darte wrote: > Oh, and by the way... > You seem to feel strongly about such an ARIN policy, perhaps you should > propose it. I or any other AC member would be happy to help you craft > the proposal and ensure that it wide distribution for possible > consensus. > > bd > > > -----Original Message----- > > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf > > Of William Herrin > > Sent: Wednesday, May 16, 2007 12:08 PM > > To: Bill Darte > > Cc: PPML at arin.net > > Subject: Re: [ppml] getting converts to V6 > > > > > > On 5/16/07, Bill Darte wrote: > > > Yup...you've had a free ride and are still getting a free ride > > > administratively from ARIN and to think that privelege > > should entitle > > > you to more free privelege seems removed from reality. > > > > Bill, > > > > That's what the objections to automatically assigning v6 > > space to all current v4 holders boil down to. The legacy v4 > > holders didn't pay their fair share of the ARIN boards' plane > > tickets to Puerto Rico. During the transition to IPv6 you > > want to correct this "mistake." > > > > IPv4 space is running out and IPv6 is not on track to wide > > deployment prior to that crunch. Is it good judgement to > > pursue a trifling inequity in the face of a looming crisis? > > > > If being unfair helps get IPv6 deployed to ubiquity, DO IT. > > > > Regards, > > Bill Herrin > > > > > > -- > > William D. Herrin herrin at dirtside.com bill at herrin.us > > 3005 Crane Dr. Web: > > Falls Church, VA 22042-3004 > > > _______________________________________________ > 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 > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From randy at psg.com Wed May 16 13:48:12 2007 From: randy at psg.com (Randy Bush) Date: Wed, 16 May 2007 07:48:12 -1000 Subject: [ppml] getting converts to V6 In-Reply-To: References: Message-ID: <464B43DC.2070003@psg.com> hint: ipv6 is not a religious crusade. well, for some it obviously is, see $subject. but as prudent engineers and shepherds of internet resources, there should be no religion, attempts to convert the uninterested and unwilling, ... people will use ipv6 when it is to their advantage and no sooner. end. some people will use us and these lists and processes when it is to their advantage. the recent and ongoing dos attack on the rir policy lists and processes being a great case in point. randy From BillD at cait.wustl.edu Wed May 16 13:52:07 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 16 May 2007 12:52:07 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <1070516133342.917B-100000@Ives.egh.com> Message-ID: John Santos wrote: > > > I have no problem with the current policy. I have my class C > and don't need any more. > > However, you people do seem to have a problem and want to > force us little guys into selling our souls to some big ISP, > except we don't get anything from this, instead we have to > pay through the nose. Precisely what 'people' are you referring to? And, in what way does it seem we are trying to force you into 'selling your souls' to a big ISP; I really don't understand what you are referring to.... > > How much does it actually cost to maintain a single record, a > few hundred bytes of information that never changes? > > As best I can tell, you would want to charge me several > hundred dollars a year, close to a dollar per address, > whereas large ISPs get addresses for a fraction of a penny per year. > > > You guys want people to jump on the IPv6 bandwagon. You > really want them to jump on the money wagon. I, for one, what people to have connectivity. You seem to have yours. I'm truly glad. I don't want you to move to IPv6 unless you need it. I want IPv6 to emerge (if it is going to) to provide connectivity options to those who will come later and not be able to get a v4 block like yours. > > Not bloody likely. > and apparently no need.... > > > > > On Wed, 16 May 2007, Bill Darte wrote: > > > Oh, and by the way... > > You seem to feel strongly about such an ARIN policy, perhaps you > > should propose it. I or any other AC member would be happy to help > > you craft the proposal and ensure that it wide distribution for > > possible consensus. > > > > bd > > > > > -----Original Message----- > > > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf > > > Of William Herrin > > > Sent: Wednesday, May 16, 2007 12:08 PM > > > To: Bill Darte > > > Cc: PPML at arin.net > > > Subject: Re: [ppml] getting converts to V6 > > > > > > > > > On 5/16/07, Bill Darte wrote: > > > > Yup...you've had a free ride and are still getting a free ride > > > > administratively from ARIN and to think that privelege > > > should entitle > > > > you to more free privelege seems removed from reality. > > > > > > Bill, > > > > > > That's what the objections to automatically assigning v6 > > > space to all current v4 holders boil down to. The legacy v4 > > > holders didn't pay their fair share of the ARIN boards' plane > > > tickets to Puerto Rico. During the transition to IPv6 you > > > want to correct this "mistake." > > > > > > IPv4 space is running out and IPv6 is not on track to wide > > > deployment prior to that crunch. Is it good judgement to > > > pursue a trifling inequity in the face of a looming crisis? > > > > > > If being unfair helps get IPv6 deployed to ubiquity, DO IT. > > > > > > Regards, > > > Bill Herrin > > > > > > > > > -- > > > William D. Herrin herrin at dirtside.com > bill at herrin.us > > > 3005 Crane Dr. Web: > > > > Falls Church, VA 22042-3004 > > > > > _______________________________________________ > > 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 > > > > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > _______________________________________________ > 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 Ed.Lewis at neustar.biz Wed May 16 14:13:15 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 16 May 2007 14:13:15 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <1070516133342.917B-100000@Ives.egh.com> References: <1070516133342.917B-100000@Ives.egh.com> Message-ID: This is the message wanted to reply to... At 1:42 PM -0400 5/16/07, John Santos wrote: >I have no problem with the current policy. I have my class C and >don't need any more. > >However, you people do seem to have a problem and want to force >us little guys into selling our souls to some big ISP, except we >don't get anything from this, instead we have to pay through the >nose. If this is the impression given by the RIRs, then the RIRs are not doing what I think we should be doing. >How much does it actually cost to maintain a single record, a few >hundred bytes of information that never changes? Not much, and I would argue that the value in the maintenance of the record is far greater to me, a paying member, than to the legacy holder. The beneficiaries of the registration function of ARIN are all those that ever check to see where a packet came from, member or non. Where we get tied up is trying to apply other value-added services, like resource certification. I don't think that ARIN ought to certify any registration to an individual/organization that it does not have a defined relationship with. (I'm being loose with words here, as I don't know how I'd deal with a POC that is a member and uses PGP authentication mode to manage a legacy block.) >As best I can tell, you would want to charge me several hundred >dollars a year, close to a dollar per address, whereas large ISPs >get addresses for a fraction of a penny per year. That would be unreasonable - unless you were benefiting commensurably. Certainly small space holders should not be subsidizing large space holders. >You guys want people to jump on the IPv6 bandwagon. You really want >them to jump on the money wagon. > >Not bloody likely. I don't think we guys want anyone to jump anywhere. The fact is that the IPv4 address space is not big enough for a global Internet Protocol infrastructure, so I guess we do encourage people to jump off that raft. I think that the value in moving to a larger address space technology has real value, all other things being equal. Joining IPv6 now is different from joining IPv4 before. In the old days, you could get address space "free" because any benefit if the space came at a high risk (the Internet was an unknown quantity then) and there was little perceived need for responsible use rules (not much to steal then). Nowadays, the value of being on the Internet is a known quantity and there are things to steal (DDoS, credit card databases, etc.) so there is justification for higher barriers to entry. Not necessarily cost but at least documentation, an agreement on terms, and some means to interact securely with the registry. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From BillD at cait.wustl.edu Wed May 16 14:24:22 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 16 May 2007 13:24:22 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <3c3e3fca0705161102p65818944ge54d77baf814d288@mail.gmail.com> Message-ID: > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf > Of William Herrin > Sent: Wednesday, May 16, 2007 1:02 PM > To: Bill Darte > Cc: PPML at arin.net > Subject: Re: [ppml] getting converts to V6 > > > On 5/16/07, Bill Darte wrote: > > Should we pay them to take it, pay them to use it? > > You say that in jest, but consider it seriously for a moment. > Pay any web server operator who fills out a form a hundredth > of a cent for every unique IPv6 address that visits their > sites this year and IPv6 adoption will skyrocket. Webmasters > wouldn't be able to move to IPv6 ISPs fast enough and they'd > be motivated to reward IPv6 users with something extra. I really didn't say it in jest? I just don't see ARIN's role as advocacy. I think it is ARIN's role to allocate number resources. It makes available v4 addresses and v6 addresses. They are there....and ARIN (you, me, the industry) has gone out of its way to ensure that there are limited barriers to entry for those that want v6. > > I don't propose such a system. Its too easily scammed and > ARIN lacks the staff to stay on top of the fraud issues. But > it would certainly solve the looming IPv4 crisis. > > > > What remedy is it to give legacy holders another legacy > block and have > > them outside of the system the industry endorses as the means to > > provide fair and professional oversight to Internet number > resources? > > Why must assigning another block be linked with keeping them > outside the system? Think outside the box and come up with a > way to use an IPv6 giveaway as a lever to bring the > still-active legacy v4 folks into the fold. They won't want > to pay for a new assignment, but I'll bet most would sign an > RSA and start paying the $100 annual maintenance fee if there > was something in it for them. Exactly.....when people see that IPv6 has something in it for them, they will move. Subsidizing people to have those addresses only to receive the subsidy seems very artificial to me. > > > You seem to feel strongly about such an ARIN policy, perhaps you > > should propose it. I or any other AC member would be happy to help > > you craft the proposal and ensure that it wide distribution for > > possible consensus. > > Fair enough. I'll send you a draft for comments some time next week. I look forward to working with you.... > > Regards, > Bill Herrin > > > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > From kkargel at polartel.com Wed May 16 14:27:47 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 16 May 2007 13:27:47 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <1070516133342.917B-100000@Ives.egh.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706F23@mail> Here Here John! I am glad you wrote in. I see so many people here trying to arrange things so that they can make more money, and are not worrying about what will make the internet(s) actually work better. Forcing people to make changes with artificially inflated costs is just plain bad practice, except of course for the guy that's collecting the fees. I really don't understand the push to force people over to IPv6 and make them abandon their v4 space. If the v4 space is meeting their needs why not let them run with it? Eventually they will need to migrate over when resources and content are only available on v6, but why bully them into changing? I doubt that those little folks are providing much content that is vital to your network. The migration to IPv6 will happen. It will happen whether we riot an run amok, and it will happen if we sit passively and watch. I suspect that it will happen on nearly the same schedule in either case. Those who are aware and forward thinking will have a more seamless and inexpensive transition, those who wait till the last minute will have a harder time of it and spend more money. But it is still their choice, We can educate, but we don't have the right to drag them along kicking and screaming. If you bully guys out there are really so into the almighty dollar, then why not change to an industry that is all about money and has nothing to do with ethics or morality.. something like TV evangalism maybe.. Kevin $s/worry/happy,g > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of John Santos > Sent: Wednesday, May 16, 2007 12:42 PM > To: PPML at arin.net > Subject: Re: [ppml] getting converts to V6 > > > > I have no problem with the current policy. I have my class C > and don't need any more. > > However, you people do seem to have a problem and want to > force us little guys into selling our souls to some big ISP, > except we don't get anything from this, instead we have to > pay through the nose. > > How much does it actually cost to maintain a single record, a > few hundred bytes of information that never changes? > > As best I can tell, you would want to charge me several > hundred dollars a year, close to a dollar per address, > whereas large ISPs get addresses for a fraction of a penny per year. > > > You guys want people to jump on the IPv6 bandwagon. You > really want them to jump on the money wagon. > > Not bloody likely. > > > > > > On Wed, 16 May 2007, Bill Darte wrote: > > > Oh, and by the way... > > You seem to feel strongly about such an ARIN policy, perhaps you > > should propose it. I or any other AC member would be happy to help > > you craft the proposal and ensure that it wide distribution for > > possible consensus. > > > > bd > > > > > -----Original Message----- > > > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of > > > William Herrin > > > Sent: Wednesday, May 16, 2007 12:08 PM > > > To: Bill Darte > > > Cc: PPML at arin.net > > > Subject: Re: [ppml] getting converts to V6 > > > > > > > > > On 5/16/07, Bill Darte wrote: > > > > Yup...you've had a free ride and are still getting a free ride > > > > administratively from ARIN and to think that privelege > > > should entitle > > > > you to more free privelege seems removed from reality. > > > > > > Bill, > > > > > > That's what the objections to automatically assigning v6 space to > > > all current v4 holders boil down to. The legacy v4 holders didn't > > > pay their fair share of the ARIN boards' plane tickets to Puerto > > > Rico. During the transition to IPv6 you want to correct this > > > "mistake." > > > > > > IPv4 space is running out and IPv6 is not on track to wide > > > deployment prior to that crunch. Is it good judgement to pursue a > > > trifling inequity in the face of a looming crisis? > > > > > > If being unfair helps get IPv6 deployed to ubiquity, DO IT. > > > > > > Regards, > > > Bill Herrin > > > > > > > > > -- > > > William D. Herrin herrin at dirtside.com > bill at herrin.us > > > 3005 Crane Dr. Web: > > > > Falls Church, VA 22042-3004 > > > > > _______________________________________________ > > 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 > > > > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > _______________________________________________ > 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 Wed May 16 14:52:06 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Wed, 16 May 2007 11:52:06 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: References: Message-ID: <464B52D6.7060704@bogomips.com> Cut off your nose to spite your face? IPv4 and IPv6 are just like products. IPv4 is running out, IPv6 is the new model noone wants yet. When you want to push something noone really wants just yet, you are going to have to give some of it away for free. It seems removed from reality to think you can treat IPv4 and IPv6 the same with respect to fees. IPv6 is a new frontier, if you want a stampede of people staking claims and homesteading this new wilderness you have to be prepared to give a little bit away in the beginning. Since this is the AMERICAN Registry for Internet Numbers, you'd think the historical precedents would be obvious. Bill Darte wrote: >> It may upset some but maybe the early adopters should get a >> break just for being early adopters. >> > > Yup...you've had a free ride and are still getting a free ride > administratively from ARIN and to think that privelege should entitle > you to more free privelege seems removed from reality. > > Bill Darte > ARIN AC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From billf at powerset.com Wed May 16 15:10:40 2007 From: billf at powerset.com (bill fumerola) Date: Wed, 16 May 2007 12:10:40 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <464B52D6.7060704@bogomips.com> References: <464B52D6.7060704@bogomips.com> Message-ID: <20070516191040.GE31238@elvis.mu.org> On Wed, May 16, 2007 at 11:52:06AM -0700, John Paul Morrison wrote: > Cut off your nose to spite your face? cut off your ears to spite your brain? > [...] > IPv6 is a new frontier, if you want a stampede of people staking claims > and homesteading this new wilderness you have to be prepared to give a > little bit away in the beginning. Since this is the AMERICAN Registry > for Internet Numbers, you'd think the historical precedents would be > obvious. there have been multiple references to the ways you can get involved at various commitments on this thread. there are many, many tunnel brokers. there are end user allocations for existing resource holders (i just got mine for $500, hardly breaking the bank), there are several ipv4/ipv6 overlay addressing schemes, there is ULA, etc etc. failure on your part to investigate the plethora of options and pick the one that meets your fiscal and technical goals does not constitute a failure on ARIN's stewardship of the space allocated to the region. spend five minutes researching available options for every one minute spent mailing ppml@ and you may find what you need has been ready for you all along. -- bill ps. also, the 'America' in 'american homesteading' and the 'America' in 'ARIN' are not the same America. http://www.arin.net/community/ARINcountries.html From kkargel at polartel.com Wed May 16 15:07:28 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 16 May 2007 14:07:28 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <464B52D6.7060704@bogomips.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706F24@mail> I will add to this that IPv6 is not a fully blown functionint internetwork.. the early adopters are assuming some level of risk as the go into virtually unexplored territory, They are also receiving less benefit from the less densly polulated address space. They will be expending more time and energy getting their networks fine tuned than the IPv4 networks. IMHO it seems that early adopters should get some kind of a break. If you don't give people a break, or stroke their ego's or something it will be hard to get any but the fanatics to jump on the bandwagon. Kevin $s/worry/happy,g ________________________________ From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of John Paul Morrison Sent: Wednesday, May 16, 2007 1:52 PM To: PPML at arin.net Subject: Re: [ppml] getting converts to V6 Cut off your nose to spite your face? IPv4 and IPv6 are just like products. IPv4 is running out, IPv6 is the new model noone wants yet. When you want to push something noone really wants just yet, you are going to have to give some of it away for free. It seems removed from reality to think you can treat IPv4 and IPv6 the same with respect to fees. IPv6 is a new frontier, if you want a stampede of people staking claims and homesteading this new wilderness you have to be prepared to give a little bit away in the beginning. Since this is the AMERICAN Registry for Internet Numbers, you'd think the historical precedents would be obvious. Bill Darte wrote: It may upset some but maybe the early adopters should get a break just for being early adopters. Yup...you've had a free ride and are still getting a free ride administratively from ARIN and to think that privelege should entitle you to more free privelege seems removed from reality. Bill Darte ARIN AC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmorrison at bogomips.com Wed May 16 15:13:44 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Wed, 16 May 2007 12:13:44 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> Message-ID: <464B57E8.3070401@bogomips.com> Privilege? That sounds very elitist. I would consider it a right to be ISP independent. I can take my phone numbers with me - home, business and even cell phone numbers now. So my ISP is allowed to hold "my" IP addresses and therefore my businesses hostage (for the greater good of the Internet), actually making the phone system more open and competitive? Scary thought. I can't argue with the technical reasons for PA addresses, but setting the bar too high for PI addresses is very anti-competitive - not that the big ISPs are complaining. Heather Schiller wrote: > On Wed, 16 May 2007, Jeroen Massar wrote: > > >>> That's a big expense just to be ISP independent. >>> >> It is indeed a huge privilege to be ISP independent. It takes a lot of >> knowledge and investment of various things to do it correctly. >> If you are incapable of doing that, then please don't. There are enough >> unmanaged networks on the Internet already and really another couple of >> them is something to avoid. >> >> >>> ARIN's frugle policy is killing the Internet off for all but the rich. >>> ARIN's annual budget is 10 million dollars, the fat cats need to just give >>> out the rest of the Ips already so we can move on to the next stage of the >>> Internet. >>> From leo.vegoda at icann.org Wed May 16 15:25:01 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 16 May 2007 21:25:01 +0200 Subject: [ppml] getting converts to V6 In-Reply-To: <464B57E8.3070401@bogomips.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> Message-ID: <583AB54F-6206-478C-9FC8-02BF3D9EAD34@icann.org> On 16 May 2007, at 9:13pm, John Paul Morrison wrote: [...] > I can't argue with the technical reasons for PA addresses, but setting > the bar too high for PI addresses is very anti-competitive - not that > the big ISPs are complaining. The bar for IPv6 is the same as for IPv4: To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect. http://www.arin.net/policy/nrpm.html#six581 Is that too high a bar? -- Leo Vegoda IANA Numbers Liaison From randy at psg.com Wed May 16 15:32:54 2007 From: randy at psg.com (Randy Bush) Date: Wed, 16 May 2007 09:32:54 -1000 Subject: [ppml] getting converts to V6 In-Reply-To: <464B52D6.7060704@bogomips.com> References: <464B52D6.7060704@bogomips.com> Message-ID: <464B5C66.7010704@psg.com> > IPv4 and IPv6 are just like products. IPv4 is running out, IPv6 is the > new model noone wants yet. When you want to push something noone really > wants just yet you have moved from stewardship to marketing From jmorrison at bogomips.com Wed May 16 15:38:19 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Wed, 16 May 2007 12:38:19 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <464B5C66.7010704@psg.com> References: <464B52D6.7060704@bogomips.com> <464B5C66.7010704@psg.com> Message-ID: <464B5DAB.4080903@bogomips.com> Is that so incompatible with facilitating the advancement of the Internet? "/Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach."/ Randy Bush wrote: >> IPv4 and IPv6 are just like products. IPv4 is running out, IPv6 is the >> new model noone wants yet. When you want to push something noone really >> wants just yet >> > > you have moved from stewardship to marketing > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmorrison at bogomips.com Wed May 16 15:39:32 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Wed, 16 May 2007 12:39:32 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <583AB54F-6206-478C-9FC8-02BF3D9EAD34@icann.org> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <583AB54F-6206-478C-9FC8-02BF3D9EAD34@icann.org> Message-ID: <464B5DF4.4000907@bogomips.com> What about the monetary bar? Leo Vegoda wrote: > On 16 May 2007, at 9:13pm, John Paul Morrison wrote: > > [...] > >> I can't argue with the technical reasons for PA addresses, but setting >> the bar too high for PI addresses is very anti-competitive - not that >> the big ISPs are complaining. > > The bar for IPv6 is the same as for IPv4: > > To qualify for a direct assignment, an organization must: > > 1. not be an IPv6 LIR; and > 2. qualify for an IPv4 assignment or allocation from ARIN under the > IPv4 policy currently in effect. > > http://www.arin.net/policy/nrpm.html#six581 > > Is that too high a bar? > From heather.schiller at verizonbusiness.com Wed May 16 15:41:14 2007 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Wed, 16 May 2007 19:41:14 +0000 (GMT) Subject: [ppml] getting converts to V6 In-Reply-To: <464B57E8.3070401@bogomips.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> Message-ID: So, why isn't your complaint that no one has built a good, reasonable, easy method or tool for renumbering or developed an assignment scheme or way of routing that would allow you to not have to renumber or renumber entirely? There's more than one way to handle a problem. Why must PI always be the answer? (because the other is harder? takes more time? more collaboration? __?) --Heather ############################################### # Heather Schiller # # Customer Security & IP Address Management # # 800.900.0241 # # security at mci.com # ############################################### On Wed, 16 May 2007, John Paul Morrison wrote: > Privilege? That sounds very elitist. I would consider it a right to be > ISP independent. I can take my phone numbers with me - home, business > and even cell phone numbers now. So my ISP is allowed to hold "my" IP > addresses and therefore my businesses hostage (for the greater good of > the Internet), actually making the phone system more open and > competitive? Scary thought. > > I can't argue with the technical reasons for PA addresses, but setting > the bar too high for PI addresses is very anti-competitive - not that > the big ISPs are complaining. > > > Heather Schiller wrote: >> On Wed, 16 May 2007, Jeroen Massar wrote: >> >> >>>> That's a big expense just to be ISP independent. >>>> >>> It is indeed a huge privilege to be ISP independent. It takes a lot of >>> knowledge and investment of various things to do it correctly. >>> If you are incapable of doing that, then please don't. There are enough >>> unmanaged networks on the Internet already and really another couple of >>> them is something to avoid. >>> >>> >>>> ARIN's frugle policy is killing the Internet off for all but the rich. >>>> ARIN's annual budget is 10 million dollars, the fat cats need to just give >>>> out the rest of the Ips already so we can move on to the next stage of the >>>> Internet. >>>> > > _______________________________________________ > 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 leo.vegoda at icann.org Wed May 16 16:05:36 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 16 May 2007 22:05:36 +0200 Subject: [ppml] getting converts to V6 In-Reply-To: <464B5DF4.4000907@bogomips.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <583AB54F-6206-478C-9FC8-02BF3D9EAD34@icann.org> <464B5DF4.4000907@bogomips.com> Message-ID: <866D24A7-EA41-42EA-9863-71E7B9DAE82A@icann.org> On 16 May 2007, at 9:39pm, John Paul Morrison wrote: > What about the monetary bar? I understand that the registration fees are intended to recover the costs involved in the registration process. Presumably you want to set the fees so low that costs are not recovered and that's obviously not sustainable for very long. However, a discussion of fees is not really on-topic for this list. Regards, -- Leo Vegoda IANA Numbers Liaison From jeroen at unfix.org Wed May 16 16:11:18 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 16 May 2007 21:11:18 +0100 Subject: [ppml] Private Internet Addresses Was: getting converts to V6 In-Reply-To: References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> Message-ID: <464B6566.7000806@spaghetti.zurich.ibm.com> [Changed subject from a religious topic to more appropriate, but still not on topic for ppml as it discusses technicalities, not policy.] Heather Schiller wrote: > So, why isn't your complaint that no one has built a good, reasonable, > easy method or tool for renumbering or developed an assignment scheme or > way of routing that would allow you to not have to renumber or renumber > entirely? There's more than one way to handle a problem. Why must PI > always be the answer? (because the other is harder? takes more time? > more collaboration? __?) I actually, kind of, agree with the fact that people will want to have their own private globally unique block of "Private Internet Addresses", you know "PI Addresses". The current routing model though does not support this. For these people I suggest they look at things like ORCHID / HIP. As these will provide people with the properties they are looking for. People seem to also confuse telephone numbers, which they can keep since a few years, with IP addresses. They are not the same. DNS is what you keep and what is independent from anything. And telephone numbers are in effect, inside the telephone system, also DNS entries. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From drc at virtualized.org Wed May 16 14:46:53 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 16 May 2007 11:46:53 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464550D9.1040506@internap.com> References: <464425E7.1070305@arin.net> <464550D9.1040506@internap.com> Message-ID: [Catching up] On May 11, 2007, at 10:30 PM, Scott Leibrand wrote: > 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. Will do. Thanks, -drc From drc at virtualized.org Wed May 16 14:51:10 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 16 May 2007 11:51:10 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: <9816B43D-50CE-4B67-9744-7256767C168F@virtualized.org> Ray, On May 13, 2007, at 1:10 AM, Ray Plzak wrote: > drc - are you concerned about auditor certification? Not sure I fully understand the question. Taking a stab at what you meant, I would consider that an operational issue outside the context of policy. That is, if policy specifies that a 3rd party audit is required, how that auditor is certified would seem to me to be something that isn't really appropriate for definition in a public policy. Rgds, -drc From vixie at vix.com Wed May 16 16:34:19 2007 From: vixie at vix.com (Paul Vixie) Date: Wed, 16 May 2007 20:34:19 +0000 Subject: [ppml] getting converts to V6 In-Reply-To: Your message of "Wed, 16 May 2007 19:41:14 GMT." References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> Message-ID: <24899.1179347659@sa.vix.com> > So, why isn't your complaint that no one has built a good, reasonable, > easy method or tool for renumbering been there, done that, got the t-shirt. (A6 and DNAME.) > or developed an assignment scheme or way of routing that would allow > you to not have to renumber or renumber entirely? in the IPng wars, many folks asserted that without a solution to the routing problem, adding more address bits would both fail to solve existing problems and also make existing problems worse and also cause new problems. as you can see, those folks lost the war. ("too little, too soon." --tli) > There's more than one way to handle a problem. Why must PI always be the > answer? (because the other is harder? takes more time? more collaboration? because it's the knob we have, on the mechanism we have, rather than the knob we wish we had on the mechanism we don't have. From stephen at sprunk.org Wed May 16 16:44:08 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 16 May 2007 15:44:08 -0500 Subject: [ppml] getting converts to V6 References: <70DE64CEFD6E9A4EB7FAF3A063141066706F23@mail> Message-ID: <031e01c797fa$fc4de510$413816ac@atlanta.polycom.com> Thus spake "Kevin Kargel" > I am glad you wrote in. I see so many people here trying to > arrange things so that they can make more money, and are > not worrying about what will make the internet(s) actually work > better. Forcing people to make changes with artificially > inflated costs is just plain bad practice, except of course for > the guy that's collecting the fees. Since the "guy" collecting the fees is actually a non-profit org that works on a cost-recovery basis, at most one could say that the fees are disproportionately applied. > I really don't understand the push to force people over to IPv6 > and make them abandon their v4 space. I don't see anyone attempting to "force" people to v6 or "make them abandon" v4. There have been discussions about (a) reclaiming v4 space that is _already_ abandoned, (b) reclaiming v4 space that is not needed but still held by legacy orgs (but not touching what is actually needed), and/or (c) enticing people to add v6 to their v4 networks (which won't go away any time soon). These things tend to come up in the same discussions regarding the pending apocalypse, but they're not tied together. > If the v4 space is meeting their needs why not let them run with > it? Eventually they will need to migrate over when resources > and content are only available on v6, but why bully them into > changing? I doubt that those little folks are providing much > content that is vital to your network. Ah, but the theory goes that by holding on to space (particularly /8s and /16s) that they don't need, they will eventually prevent people who _do_ provide valuable content from being able to get v4 space. Depending on your perspective, that may be a good or bad thing. > If you bully guys out there are really so into the almighty dollar, > then why not change to an industry that is all about money and > has nothing to do with ethics or morality.. something like TV > evangalism maybe.. I don't see any bullies here; I see a lot of people who have varying ideas of what's in the best interests of the community based on their varying experiences and perspectives. That is to be expected. Plus, the monetary debate here has little to do with ARIN's fees at present; for most orgs, the cost of getting IPv6 space (even without a waiver) is a rounding error compared to the capital and operational expenses necessary to dual-stack a network, and ARIN has absolutely no control over that. Until that problem is solved, debating fees and waivers is a waste of valuable time. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From michael.dillon at bt.com Wed May 16 17:24:45 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 May 2007 22:24:45 +0100 Subject: [ppml] getting converts to V6 Message-ID: * IPv6 is a new frontier, if you want a stampede of people staking claims * and homesteading this new wilderness you have to be prepared to give a * little bit away in the beginning. Since this is the AMERICAN Registry for * Internet Numbers, you'd think the historical precedents would be obvious. Since ARIN has a website at http://www.arin.net you'd think that anyone who takes the time to post on PPML would also take the time to do a bit of research and notice that ARIN has been following this precedent for the past 3 years or so. --Michael Dillon -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Wed May 16 17:25:39 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 May 2007 22:25:39 +0100 Subject: [ppml] getting converts to V6 In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066706F23@mail> References: <1070516133342.917B-100000@Ives.egh.com> <70DE64CEFD6E9A4EB7FAF3A063141066706F23@mail> Message-ID: > I really don't understand the push to force people over to IPv6 and make > them abandon their v4 space. I'm not sure where you see this kind of push, but it is not here at ARIN because the ARIN charter does not allow for any such activity. People may propose ill-thought-out policies but at the end of the day, the Advisory Council will water them down so that the *PUSH* is gone, or the BoT will reject them. > If you bully guys out there are really so into the almighty dollar, then > why not change to an industry that is all about money and has nothing to > do with ethics or morality.. something like TV evangalism maybe.. Please, can we keep this kind of discussion *OFF* the ARIN PPML list? --Michael Dillon From owen at delong.com Wed May 16 17:30:50 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2007 14:30:50 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <1070516133342.917B-100000@Ives.egh.com> References: <1070516133342.917B-100000@Ives.egh.com> Message-ID: On May 16, 2007, at 10:42 AM, John Santos wrote: > > > I have no problem with the current policy. I have my class C and > don't need any more. > > However, you people do seem to have a problem and want to force > us little guys into selling our souls to some big ISP, except we > don't get anything from this, instead we have to pay through the > nose. > Huh? Who do you mean by "You People"? ARIN is an organization made up of two groups of people... On one hand, you have the members, most of whom _ARE_ ISPs of various sizes. On the other hand, you have the community. The community, which is the body that actually has the greatest amount of input into ARIN policy is made up of ANYONE interested in IP policy. I have proposed IP Policy without being an ARIN member. I have see policy proposals I drafted and policy proposals I helped modify become ARIN Policy without being an ARIN member. When you say "YOU PEOPLE" like we are some amorphous body bent on causing you grief, you seem to forget that you are, by virtue of the fact that you are participating on this list, one of "YOU PEOPLE". > How much does it actually cost to maintain a single record, a few > hundred bytes of information that never changes? > It's probably a little less than the $100/year you have to pay under ARINs structure, but, you can maintain as many records as you need for that same $100/year, so, I don't think it's such a horrible deal. Since you think $100/year is too much to pay for all of your ARIN resources, could you tell us what you think would be a more reasonable price for annual service from ARIN? > As best I can tell, you would want to charge me several hundred > dollars a year, close to a dollar per address, whereas large ISPs > get addresses for a fraction of a penny per year. > Are you an ISP or an end user? Quoting from the ARIN fee page: ============= Annual Maintenance Fee ARIN assesses a consolidated annual maintenance fee of $100 (USD) for each Org ID with resources registered with ARIN to cover the cost of maintaining assignment information. Org IDs that also have direct allocations of IP address space associated with them do not have to pay this fee. ARIN will invoice organizations two months prior to the anniversary date of their first resource registration, and the payment is due by that anniversary date. In cases where a single Org ID has more than one resource registered with ARIN (e.g. AS numbers, IPv4 or IPv6 assignments, or network transfers), ARIN charges only a single maintenance fee of $100. End-users should ensure that their annual payment is made by the due date on their invoice, in accordance with the Registration Services Agreement. If not paid by the invoice due date, the address space may be revoked. ============= If you have a single record, or, as is more likely the case, even a set of records that do not change, then, you must be an end-user, because ISPs (in the ARIN sense of the term) are people who reallocate or reassign space to other organizations. Thus, ISPs do not have single records that do not change. If you are an end user, you only pay $100/year, no matter how many resources you have from ARIN. Yes, there are some additional one-time fees to process a new registration request, but, your paragraph seems to be talking about the annual fees since you mention "dollars a year". In this, you are mistaken, the fee is only $100. > > You guys want people to jump on the IPv6 bandwagon. You really want > them to jump on the money wagon. > Hardly. ARIN fees are not structured to penalize anyone. Further, ARIN is actually fairly frugal in their spending of what they do collect. Your accusations here seem specious to me. It's not like anyone at ARIN is getting paid on commission or receives any more or less money based on the amount of v6 space people use or the rate of adoption of v6. Indeed, in terms of v4 vs. v6, ARIN as an organization is pretty much agnostic. However, the reality is that eventually, we will be unable to sustain growth of new users in the IPv4 address space due to freespace exhaustion. The only solution to that problem is a larger address space. Currently, the most viable proposal for a larger address space is v6. The fact that ARIN does not want to repeat the mistakes of early IPv4 address with IPv6 is not about collecting fees. It is about being able to track whether addresses are still in use or not, and, about having the ability for address policy changes to apply to existing addresses rather than having to maintain multiple legacy policies in perpetuity. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 Wed May 16 17:57:33 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2007 14:57:33 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> Message-ID: <9EA72702-D15B-4DB1-837D-F0886BDD1231@delong.com> Because renumbering almost always involves configuration changes required on devices I don't control. That makes renumbering inherently problematic. Owen On May 16, 2007, at 12:41 PM, Heather Schiller wrote: > > So, why isn't your complaint that no one has built a good, reasonable, > easy method or tool for renumbering or developed an assignment > scheme or > way of routing that would allow you to not have to renumber or > renumber > entirely? There's more than one way to handle a problem. Why > must PI > always be the answer? (because the other is harder? takes more time? > more collaboration? __?) > > --Heather > > ############################################### > # Heather Schiller # > # Customer Security & IP Address Management # > # 800.900.0241 # > # security at mci.com # > ############################################### > > On Wed, 16 May 2007, John Paul Morrison wrote: > >> Privilege? That sounds very elitist. I would consider it a right >> to be >> ISP independent. I can take my phone numbers with me - home, business >> and even cell phone numbers now. So my ISP is allowed to hold >> "my" IP >> addresses and therefore my businesses hostage (for the greater >> good of >> the Internet), actually making the phone system more open and >> competitive? Scary thought. >> >> I can't argue with the technical reasons for PA addresses, but >> setting >> the bar too high for PI addresses is very anti-competitive - not that >> the big ISPs are complaining. >> >> >> Heather Schiller wrote: >>> On Wed, 16 May 2007, Jeroen Massar wrote: >>> >>> >>>>> That's a big expense just to be ISP independent. >>>>> >>>> It is indeed a huge privilege to be ISP independent. It takes a >>>> lot of >>>> knowledge and investment of various things to do it correctly. >>>> If you are incapable of doing that, then please don't. There are >>>> enough >>>> unmanaged networks on the Internet already and really another >>>> couple of >>>> them is something to avoid. >>>> >>>> >>>>> ARIN's frugle policy is killing the Internet off for all but >>>>> the rich. >>>>> ARIN's annual budget is 10 million dollars, the fat cats need >>>>> to just give >>>>> out the rest of the Ips already so we can move on to the next >>>>> stage of the >>>>> Internet. >>>>> >> >> _______________________________________________ >> 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 drc at virtualized.org Wed May 16 18:38:49 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 16 May 2007 17:38:49 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> Message-ID: <4CE80DC9-D80D-4F74-A2F1-932AF92BE810@virtualized.org> Hi, On May 14, 2007, at 7:20 AM, Rich Emmings wrote: > Opposed as written. OK. > 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. Hmm. I'm curious what you see as the idea that was poorly conceived in 2007-12 and weren't addressed in Soft Landing. I considered Soft Landing to be pretty much the diametric opposite of 2007-12 (no reservation, no freezing of policy). > 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".) Guilty as charged. I have not implemented IPv6 on a large scale. However, neither has most of the world, and part of the rationale behind Soft Landing is to encourage people to start. > 2) Artifically making a commodity rare, will cause a run on it > before it's rare and push up the dates. Fortunately(?), IPv4 space scarcity isn't artificial. > 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. As mentioned previously, the reason I put in a large number of phases was to avoid large changes in requirements over short periods of time. It may be with the revised exhaustion estimates that there is insufficient time to actually implement the number of phases I specified. I'll look into this. As to why there are policy changes, I thought that was explained in the rationale section. > 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. I'm not sure I'm following you. These sound like different policies that could be applied within the framework of Soft Landing. > 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. The problem with this is that it leaves people in the dark about what is going to happen in the future. I am trying to give people a roadmap so that they're aware of what is in store for them. > 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. But it also risks a disconnect and ratholing on irrelevant details. In any event, thanks for the comments even if you don't support the proposal as written. Rgds, -drc From drc at virtualized.org Wed May 16 18:53:35 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 16 May 2007 17:53:35 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066706F17@mail> References: <70DE64CEFD6E9A4EB7FAF3A063141066706F17@mail> Message-ID: <156D836F-587F-417F-B95F-A3C493776A8D@virtualized.org> Hi, On May 14, 2007, at 1:39 PM, 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, > while at the same time making IPv6 easier to use and educating > people on > the network enhancements that IPv6 provides. This would appear to be what I call the "cruise control" model of dealing with IPv4 exhaustion. The analogy is that you're driving down a road that you know has a brick wall at the end. Some folks are building a parallel highway right next to the road you're on. Not doing anything is approximately equivalent to putting the car on cruise control, leaning back, and hoping somebody builds an off ramp to the new highway before you hit the wall. My concern this approach is that I don't believe it is feasible. The problem is that people in the backseat are beginning to notice there is a wall in front of us and if we don't do something, the backseat drivers are going to do something we probably don't want them to do. I believe we need a coherent plan to deal with IPv4 exhaustion that gives people a clear idea of what is going to happen and what they need to do. > What we will see is that the big money boys with R&D teams and budgets > will migrate to IPv6, Or not, and folks will use IPv4 and NAT/ALG. > 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. I don't disagree and that's why I put in the requirements for ISPs to document support for IPv6 services and connectivity in order to obtain additional IPv4 support. > 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. The challenge is there is little incentive to build the product because there is no market. Rgds, -drc From martin.hannigan at batelnet.bs Thu May 17 10:34:37 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 17 May 2007 10:34:37 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing Message-ID: <464c67fd.281.2354.18643@batelnet.bs> David Conrad wrote: > Hi, > > On May 14, 2007, at 1:39 PM, 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, while at the same time making > > IPv6 easier to use and educating people on > > the network enhancements that IPv6 provides. > > This would appear to be what I call the "cruise control" > model of dealing with IPv4 exhaustion. The analogy is > that you're driving down a road that you know has a > brick wall at the end. Some folks are building a > parallel highway right next to the road you're on. Not > doing anything is approximately equivalent to putting the > car on cruise control, leaning back, and hoping somebody > builds an off ramp to the new highway before you hit the > wall. It's inevitable. There is an ideological split amongst RIR memberships on how to deal with this and the wedge is perceived fairness related to the allocation models that have been in use. As you know, unless all 5 RIR groups sign off on contextually identical global policies, there won't be one. If there won't be a global policy, it is likely there won't be a globally coordinated policy either. We won't be out of IP address space. We'll be out of a certain type. It's akin to moving from gasoline to diesel more than hitting a brick wall. -M< From kkargel at polartel.com Thu May 17 09:36:02 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 17 May 2007 08:36:02 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706F2E@mail> First I apologize to ARIN if my wordings seemed to point the finger that way. I do think ARIN has been doing a great job and very ethically been staying within their charter. I have nothing but trust and admiration for your staff and the work they have done. I agree that this should not be a flame/lart exchange and I apologize to everyone if I have contributed in that direction. Let's keep the discussion to technical merits. Kevin $s/worry/happy,g > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Wednesday, May 16, 2007 4:26 PM > To: PPML at arin.net > Subject: Re: [ppml] getting converts to V6 > > > I really don't understand the push to force people over to IPv6 and > make > > them abandon their v4 space. > > I'm not sure where you see this kind of push, but it is not > here at ARIN because the ARIN charter does not allow for any > such activity. People may propose ill-thought-out policies > but at the end of the day, the Advisory Council will water > them down so that the *PUSH* is gone, or the BoT will reject them. > > > If you bully guys out there are really so into the almighty dollar, > then > > why not change to an industry that is all about money and > has nothing > to > > do with ethics or morality.. something like TV evangalism maybe.. > > Please, can we keep this kind of discussion *OFF* the ARIN PPML list? > > --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 drc at virtualized.org Thu May 17 01:16:29 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 17 May 2007 00:16:29 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <009b01c7971d$9768ebf0$463816ac@atlanta.polycom.com> References: <20070514205007.GB24337@vacation.karoshi.com.> <009b01c7971d$9768ebf0$463816ac@atlanta.polycom.com> Message-ID: [Putting on my IANA hat for a second, I'd send from my ICANN email address, but it would bounce] On May 15, 2007, at 1:19 PM, Stephen Sprunk wrote: > IANA could release some historically reserved space such as 0/8 and > 1/8 to > the RIRs, I am skeptical we'd be able to "unreserve" 0/8, 127/8, and the RFC 1918 space. All other reserved addresses (including 1/8 and 14/8 which the IANA Number Liaison, Leo Vegoda, has been doing a fantastic job tracking registrants down) should consider their days of wine, song, and kicking back to watch the world go by near its end. > and there's a side discussion about opening up 240/4, however IANA > expects the IETF to publish an RFC on such things first, Yep. Some folks are working on a draft to do just this. Rgds, -drc From drc at virtualized.org Thu May 17 10:30:47 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 17 May 2007 09:30:47 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> Message-ID: <1DF543FC-F0EC-4832-894F-DC8EDC5B7822@virtualized.org> Ed, On May 14, 2007, at 1:16 PM, Edward Lewis wrote: > 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. That was my understanding and why I decided to focus on PA. > Maybe it has too many steps. I'm sure that can be sanded down. Yes, perhaps. > I think the auditing cost ought to remain on the LIR/ISP as this is > their request for space. OK. > I assume that this isn't retroactive. I'm not sure what this means. > 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. I personally believe there is a problem with the process in that it takes so long, but dealing with that is a bit outside the scope of the "Soft Landing" proposal. Ideally, I would agree that if there is consensus in the ARIN region that this policy is appropriate, it should apply to other regions since the obvious downside of not being a global policy is that it will strongly increase the incentive to "registry shop". However, I thought it important to see how at least one community reacted to the policy proposal before considering pushing it global. > 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. Actually, it isn't a question about stopping growing so much as the cost of growth will no longer be predictable. Those desperate enough (and with enough money/power) will always be able to obtain the address space they need. However, I believe at some point, the cost of obtaining IPv4 (either monetary or in terms of bureaucratic red tape) is going to outweigh the cost of migrating to IPv6. Part of the goal of the "Soft Landing" policy proposal is to gradually increase the (bureaucratic red tape) costs of obtaining IPv4 over time instead of going from (essentially) $0 to $ over night, thereby giving people time to adjust. Rgds, -drc From drc at virtualized.org Thu May 17 01:27:43 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 17 May 2007 00:27:43 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <24899.1179347659@sa.vix.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <24899.1179347659@sa.vix.com> Message-ID: <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> On May 16, 2007, at 3:34 PM, Paul Vixie wrote: >> So, why isn't your complaint that no one has built a good, >> reasonable, >> easy method or tool for renumbering > been there, done that, got the t-shirt. (A6 and DNAME.) A t-shirt would likely have worked better in supporting renumbering than A6 and DNAME... (I think that dead horse isn't even organic residue anymore) >> or developed an assignment scheme or way of routing that would allow >> you to not have to renumber or renumber entirely? > > in the IPng wars, many folks asserted that without a solution to the > routing problem, adding more address bits would both fail to solve > existing problems and also make existing problems worse and also cause > new problems. as you can see, those folks lost the war. ("too > little, > too soon." --tli) Sorry, what problem? I've been told "just build bigger routers" so many times now, maybe a million lemmings might not be wrong. >> There's more than one way to handle a problem. Why must PI always >> be the >> answer? (because the other is harder? takes more time? more >> collaboration? > because it's the knob we have, on the mechanism we have, rather > than the knob > we wish we had on the mechanism we don't have. Given the state of affairs, namely: - all RIRs are liberalizing PI allocation policies. - many believe there is no problem in routing that can't be solved by throwing bigger/faster (although they admit, not necessarily cheaper) boxes at it. - the IETF appears to have gone into navel gazing wait state. It is difficult for me to envision a future where there will be any significant change to IPv6 architecture that might permit realistic site-wide renumbering. But we have time yet... Rgds, -drc From rich at nic.umass.edu Thu May 17 10:39:42 2007 From: rich at nic.umass.edu (Rich Emmings) Date: Thu, 17 May 2007 10:39:42 -0400 (EDT) Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <4CE80DC9-D80D-4F74-A2F1-932AF92BE810@virtualized.org> References: <464425E7.1070305@arin.net> <4CE80DC9-D80D-4F74-A2F1-932AF92BE810@virtualized.org> Message-ID: On Wed, 16 May 2007, David Conrad wrote: > Hmm. I'm curious what you see as the idea that was poorly conceived in > 2007-12 and weren't addressed in Soft Landing. I considered Soft Landing to > be pretty much the diametric opposite of 2007-12 (no reservation, no freezing > of policy). Creation of artificially early dates for restriction to resources will increase demand for those resources earlier. One example that comes to mind is US 1970's gas distribution issues. >> 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".) > > Guilty as charged. I have not implemented IPv6 on a large scale. However, > neither has most of the world, and part of the rationale behind Soft Landing > is to encourage people to start. I think the existing ARIN policies have done a great job at encouraging those who can start, to start, but you can't push a rope: Full support in some routing platforms only just got here. Tools like ndp (think arp) are not present, or not easily present on hosts. Not all ISP's support IPv6 yet. Changing ISP's can be a problem unless you do it often. Not all other "hardware" is ready. Drop your average firewall into the mix, and it starts to get ugly real fast. SCADA is another area where we see deficiency, and worse, it's a growing area. Remote monitoring means RFC1918 is not always an option. People keep trying to rewrite the IPv6 RFC's, and while some of those don't have a real operational impact, it makes it easy for people to say "Don't implement, they're still defining it. We don't want a bloody nose for being an early adapter." Makes it harder to get support to go forward. Like it or not, Windows is a poplar platform, but it's only in Vista that they _support_ IPv6. It's in other versions, but not supported. (If someone wants to start a thread on barriers to entry to IPv6 and solutions to get over, around or though those barriers, it might informative to hear from those that are further along.) I've been pushing for starting IPv6 for lot of years now, because I think it's going to take at least 5 years to go from "start" to "supportable" so starting early makes sense. But implementation has been all working around problems and bloody noses. >> 2) Artifically making a commodity rare, will cause a run on it before it's >> rare and push up the dates. > > Fortunately(?), IPv4 space scarcity isn't artificial. > But pushing up the date when we limit assignments is artificial exhaustion. Call it hoarding, or call rationing, but it's artificial. IP addresses are only useful when used. The last block of IPv4 addresses serves no function when it's sitting on the sitting on the shelf. What will happen when the last IPv4 address is used? The Internet will still be there. What will happen is speculation, with some guesses more accurate than others. > I'm not sure I'm following you. These sound like different policies that > could be applied within the framework of Soft Landing. If thing are this critical, then we need to change the allocation policies now, not when we reach an artificial date. If things are not critical, the existing polices are ok. > The problem with this is that it leaves people in the dark about what is > going to happen in the future. I am trying to give people a roadmap so that > they're aware of what is in store for them. > In the long run, we're all 6 feet under, and we'll run out of IP addresses too (IPv4 and IPv6). So we're looking at medium term solutions. We do a full roadmap, we're trying to predict the future. Do that anywhere reliability, and you'll make far more cash in the stock market than in data processing. "This is what will happen next" still provides some information about the future without expending a lot of time roadmapping a future that may not happen. Behavior under that system allows experience to feed back into the next step. We may as well be having the conversation about Social Security, a number of the issues and proposed solutions are not analogous, but similar at a basic level, and potentially just as contentious. From owen at delong.com Thu May 17 10:51:14 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 17 May 2007 07:51:14 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <24899.1179347659@sa.vix.com> <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> Message-ID: <59C0DA2C-5032-400A-83C4-EBA919D5B1CE@delong.com> >> in the IPng wars, many folks asserted that without a solution to the >> routing problem, adding more address bits would both fail to solve >> existing problems and also make existing problems worse and also >> cause >> new problems. as you can see, those folks lost the war. ("too >> little, >> too soon." --tli) > > Sorry, what problem? I've been told "just build bigger routers" so > many times now, maybe a million lemmings might not be wrong. > The lemmings are wrong. There is no feasible way to scale a routing solution that continues to overload the end system identifier and routing locator onto the same number. In the end, even the telcos have abandoned this idea, and it is long past the time when IP should have in the IDR world. >>> There's more than one way to handle a problem. Why must PI always >>> be the >>> answer? (because the other is harder? takes more time? more >>> collaboration? >> because it's the knob we have, on the mechanism we have, rather >> than the knob >> we wish we had on the mechanism we don't have. > > Given the state of affairs, namely: > > - all RIRs are liberalizing PI allocation policies. > - many believe there is no problem in routing that can't be solved by > throwing bigger/faster (although they admit, not necessarily cheaper) > boxes at it. No... What many of us believe is that until the routing problem is made meaningful again, it won't get worked on. We also believe that the existing hacks are no longer tolerable. Finally, at least in the US, Sarbanes Oxley virtually guarantees that an increasing number of organizations MUST use provider independent addressing to meet auditing criteria. > - the IETF appears to have gone into navel gazing wait state. This is not a meaningful difference from the IETF engineering state over the development of IPv6. Of about 3 primary concerns placed on the plate of IPNG working group, they solved only one. The one they solved was adequately solved by TUBA, but, they chose, instead, to implement a more complex solution in the name of solving the other 2. Then, they abandoned the other 2 as "too hard". The three: 1. Need a bigger address space. 2. Need a scalable routing solution. 3. Need to make renumbering easy if we want to keep the PA model viable. What was actually accomplished was: 1. Bigger address space. 2. No effort whatsoever was made in this area. 3. They attempted to ram a non-viable PA model down the track thinking that no-one in operations would dare defy the all powerful IETF. I dared, and, apparently the community agreed with me, at least to some extent. > > It is difficult for me to envision a future where there will be any > significant change to IPv6 architecture that might permit realistic > site-wide renumbering. But we have time yet... > Right. As such, I think, instead, we should focus on fixing routing. That is possible. Here's how: Using options, the destination AS of a packet headed to a non-local prefix (non-local being defined as orginating from an external ASN) can be encoded in the packet by a router prior to its departure from the local AS. Then, all transit AS can forward the packet strictly based on the destination AS without ever even looking at the prefix. The lookup to map Prefix->origin AS can be done in a distributed fashion similar to DNS, and, since it can be moved relatively close to the edge, it can scale fairly reasonably. At that point, the EBGP state information required is reduced to AS Paths, next hops, and metrics. IBGP would contain the EBGP AS Path/Next Hop/Metric information and may need to include the local Prefix data (but, probably not, that can probably be handled by a parallel IGP). This could be implemented incrementally and modularly, although the EBGP savings could not be realized until deployment was sufficiently widespread that the BGP table no longer has to haul around prefixes. This can be done strictly with software upgrades to existing routers, although there may be some platforms where new ASICs would be required to achieve full speed forwarding with this method. The first step, however, is to agree upon a method. If we fix routing, then, we no longer need to solve renumbering because renumbering becomes unnecessary and PI for everyone becomes feasible. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From jeroen at unfix.org Thu May 17 11:48:04 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 17 May 2007 16:48:04 +0100 Subject: [ppml] Alternative Routing Methods (Was: getting converts to V6) In-Reply-To: <59C0DA2C-5032-400A-83C4-EBA919D5B1CE@delong.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <24899.1179347659@sa.vix.com> <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> <59C0DA2C-5032-400A-83C4-EBA919D5B1CE@delong.com> Message-ID: <464C7934.2050803@spaghetti.zurich.ibm.com> [ Changing subjects is actually handy, more ppml OT'ness ] Owen DeLong wrote: [..] > Right. As such, I think, instead, we should focus on fixing routing. > That is possible. Here's how: > > Using options, the destination AS of a packet headed to a non-local > prefix (non-local being defined as orginating from an external ASN) > can be encoded in the packet by a router prior to its departure from > the local AS. Then, all transit AS can forward the packet strictly based > on the destination AS without ever even looking at the prefix. You do realize that ASN's are nowadays 32bits and as such you are actually just encoding the next-hop IPv4 address in the packet? A gateway to say, more or less. As such, you can possibly, still end up with 2^32 of addresses. Or to make it easier, to use this, just use 6to4. Use IPv4 in the 'backbone routing tables' and give everybody as 6to4 /48. You could even trow out the first 16 bits and make it just :::/32. Or use ASN's there directly of course. Do note that we already have /32's for most sites, except PI, so you are back to square 1. > The lookup to map Prefix->origin AS can be done in a distributed > fashion similar to DNS How exactly are you going to reach that "DNS" when, to get there, you need to look up an address in that DNS. It is like saying that one should call the directory services to then be able to look up the number for directory services that you need to be able to call directory services, repeat ad infinitum. In case you really think this solution is a the golden pie, please write it up in a draft text, add some pictures to clarify it much better, post it to some nice place (IETF seems like an idea, e2e list too). Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From stephen at sprunk.org Thu May 17 11:41:43 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 17 May 2007 10:41:43 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing References: <20070514205007.GB24337@vacation.karoshi.com.> <009b01c7971d$9768ebf0$463816ac@atlanta.polycom.com> Message-ID: <010401c7989b$aca9f200$453816ac@atlanta.polycom.com> Thus spake "David Conrad" > On May 15, 2007, at 1:19 PM, Stephen Sprunk wrote: >> IANA could release some historically reserved space such as >> 0/8 and 1/8 to the RIRs, > > I am skeptical we'd be able to "unreserve" 0/8, 127/8, and the > RFC 1918 space. All other reserved addresses (including 1/8 and 14/8 > which the IANA Number Liaison, Leo Vegoda, has > been doing a fantastic job tracking registrants down) should > consider their days of wine, song, and kicking back to watch > the world go by near its end. 1/8 is not usable for human reasons. 10/8 and 192.168/16 are not recoverable because that'd give people nothing left to NAT with, and NAT is about to become even more prevalent than it already is as people desperately try to avoid migrating to v6. 172.16/12 could probably be reduced to 172.16/16 without much grief, but pulling 172.16/16 would be tough (though not as bad as 192.168/16). >> and there's a side discussion about opening up 240/4, >> however IANA expects the IETF to publish an RFC on such >> things first, > > Yep. Some folks are working on a draft to do just this. 255/8 is tough to unreserve in practice for the same reasons as 0/8 and 127/8, so it's probably not 240/4 but rather 240-254/8. If we're going to do that, we might as well switch 225-238/8 to unicast too -- only 224/8 and 239/8 see much use in the (miniscule) multicast world, and the exceedingly few oddballs using 225-238/8 could migrate to the remaining two /8s with minimal hassle. So, we could theoretically open up 29 new /8s just by writing an RFC. In reality, that's what, a couple more years of v4 space in exchange for billions of dollars in upgrades and time? That's on par with the cost of just doing v6 now -- and we'll still have to pay that v6 cost later anyways. (Also, the idea of opening those /8s up only for private use is IMHO daft and merits RFC publication on 1 Apr. Anyone who is looking to deploy a new private network that'll be incompatible with the rest of the world would use v6 and ULAs -- and that solution already exists today without any need for new RFCs or product upgrades.) 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 pete.templin at texlink.com Thu May 17 12:07:24 2007 From: pete.templin at texlink.com (Pete Templin) Date: Thu, 17 May 2007 11:07:24 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing Message-ID: <74E9F3444C71374BBC58FEA29FC2E5110883ABA0@mail.texlinkcom.com> -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Stephen Sprunk Sent: Thursday, May 17, 2007 10:42 AM To: David Conrad Cc: Public Policy Mailing List Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing 1/8 is not usable for human reasons. 10/8 and 192.168/16 are not recoverable because that'd give people nothing left to NAT with, and NAT is about to become even more prevalent than it already is as people desperately try to avoid migrating to v6. 172.16/12 could probably be reduced to 172.16/16 without much grief, but pulling 172.16/16 would be tough (though not as bad as 192.168/16). Time out - what on EARTH makes 172.16/12 (with or without 172.16/16) special enough to be reclaimed? I quote from RFC1918: "An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry." Nothing in that statement gives special exception to any of the address ranges listed in the RFC. Pete Templin Manager of Data Operations TexLink Communications (210) 892-4183 pete.templin at texlink.com This e-mail and any files transmitted with it are the property of TexLink Communications Inc and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing or copying of this e-mail is strictly prohibited. From Dan.Thorson at seagate.com Thu May 17 12:21:50 2007 From: Dan.Thorson at seagate.com (Dan.Thorson at seagate.com) Date: Thu, 17 May 2007 11:21:50 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <010401c7989b$aca9f200$453816ac@atlanta.polycom.com> Message-ID: > 1/8 is not usable for human reasons. 10/8 and 192.168/16 are not > recoverable because that'd give people nothing left to NAT with, and NAT is > about to become even more prevalent than it already is as people desperately > try to avoid migrating to v6. 172.16/12 could probably be reduced to > 172.16/16 without much grief, but pulling 172.16/16 would be tough (though > not as bad as 192.168/16). Those of us in the corporate world use significant portions of the 172.16 /12, as well as 10/8 and 192.168/16. RFC1918 needs to be sacred ground. > 255/8 is tough to unreserve in practice for the same reasons as 0/8 and > 127/8, so it's probably not 240/4 but rather 240-254/8. If we're going to > do that, we might as well switch 225-238/8 to unicast too -- only 224/8 and > 239/8 see much use in the (miniscule) multicast world, and the exceedingly > few oddballs using 225-238/8 could migrate to the remaining two /8s with > minimal hassle. There is danger in the assumption that there is a "(miniscule) multicast world". Whereas this is likely true on the Big-I Internet, multicast is widely used in the corporate manufacturing world. Who is prepared to pay the price of lost connectivity when traditional multicast IP's are suddenly deployed as end-user IP's? Who will be modifying all my legacy system's IP stacks? I'm afraid I don't have much to offer in the way of solutions... I simply call for caution when making assumptions of what is actually "used" re: RFC1918 and multicast IP's. danT =================================================== Dan Thorson - Seagate Technology - CCIE 10754 desk +1 (952) 402-8293 fax +1 (952) 402-1007 SeaTel 8-402-8293 =================================================== From tme at multicasttech.com Thu May 17 12:35:02 2007 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 17 May 2007 12:35:02 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <010401c7989b$aca9f200$453816ac@atlanta.polycom.com> References: <20070514205007.GB24337@vacation.karoshi.com.> <009b01c7971d$9768ebf0$463816ac@atlanta.polycom.com> <010401c7989b$aca9f200$453816ac@atlanta.polycom.com> Message-ID: <90FC4FB8-A2F6-46CF-A226-CD1572BDCA3D@multicasttech.com> On May 17, 2007, at 11:41 AM, Stephen Sprunk wrote: > Thus spake "David Conrad" >> On May 15, 2007, at 1:19 PM, Stephen Sprunk wrote: >>> IANA could release some historically reserved space such as >>> 0/8 and 1/8 to the RIRs, >> >> I am skeptical we'd be able to "unreserve" 0/8, 127/8, and the >> RFC 1918 space. All other reserved addresses (including 1/8 and 14/8 >> which the IANA Number Liaison, Leo Vegoda, has >> been doing a fantastic job tracking registrants down) should >> consider their days of wine, song, and kicking back to watch >> the world go by near its end. > > 1/8 is not usable for human reasons. 10/8 and 192.168/16 are not > recoverable because that'd give people nothing left to NAT with, > and NAT is > about to become even more prevalent than it already is as people > desperately > try to avoid migrating to v6. 172.16/12 could probably be reduced to > 172.16/16 without much grief, but pulling 172.16/16 would be tough > (though > not as bad as 192.168/16). > >>> and there's a side discussion about opening up 240/4, >>> however IANA expects the IETF to publish an RFC on such >>> things first, >> >> Yep. Some folks are working on a draft to do just this. > > 255/8 is tough to unreserve in practice for the same reasons as 0/8 > and > 127/8, so it's probably not 240/4 but rather 240-254/8. If we're > going to > do that, we might as well switch 225-238/8 to unicast too -- only > 224/8 and > 239/8 see much use in the (miniscule) multicast world, and the > exceedingly > few oddballs using 225-238/8 could migrate to the remaining two /8s > with > minimal hassle. > I assume that this is satire and / or sarcasm. If not, you will get push back here. Regards Marshall > So, we could theoretically open up 29 new /8s just by writing an > RFC. In > reality, that's what, a couple more years of v4 space in exchange for > billions of dollars in upgrades and time? That's on par with the > cost of > just doing v6 now -- and we'll still have to pay that v6 cost later > anyways. > > (Also, the idea of opening those /8s up only for private use is > IMHO daft > and merits RFC publication on 1 Apr. Anyone who is looking to > deploy a new > private network that'll be incompatible with the rest of the world > would use > v6 and ULAs -- and that solution already exists today without any > need for > new RFCs or product upgrades.) > > 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 tony at lava.net Thu May 17 12:43:38 2007 From: tony at lava.net (Antonio Querubin) Date: Thu, 17 May 2007 06:43:38 -1000 (HST) Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: On Thu, 17 May 2007, Dan.Thorson at seagate.com wrote: > exceedingly >> few oddballs using 225-238/8 could migrate to the remaining two /8s with >> minimal hassle. > > There is danger in the assumption that there is a "(miniscule) multicast > world". Whereas this is likely true on the Big-I Internet, multicast is > widely used in the corporate manufacturing world. Who is prepared to pay Concur on this. There're quite a few small multicast islands out there. Requiring those of us who are using that space for global connectivity to squeeze down to just 224/8 doesn't leave much wiggle room. Antonio Querubin whois: AQ7-ARIN From BillD at cait.wustl.edu Thu May 17 12:45:32 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Thu, 17 May 2007 11:45:32 -0500 Subject: [ppml] Reclamation - Rededication of Address Space - was Policy Proposal: IPv4 Soft Landing In-Reply-To: Message-ID: I suggest that this discussion is off-topic to the IPv4 Soft Landing policy proposal discussion. Bill Darte ARIN AC and proposal shepherd > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Dan.Thorson at seagate.com > Sent: Thursday, May 17, 2007 11:22 AM > To: Public Policy Mailing List > Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > > > > 1/8 is not usable for human reasons. 10/8 and 192.168/16 are not > > recoverable because that'd give people nothing left to NAT > with, and > > NAT > is > > about to become even more prevalent than it already is as people > desperately > > try to avoid migrating to v6. 172.16/12 could probably be > reduced to > > 172.16/16 without much grief, but pulling 172.16/16 would be tough > (though > > not as bad as 192.168/16). > > Those of us in the corporate world use significant portions > of the 172.16 /12, as well as 10/8 and 192.168/16. RFC1918 > needs to be sacred ground. > > > 255/8 is tough to unreserve in practice for the same reasons as 0/8 > > and 127/8, so it's probably not 240/4 but rather 240-254/8. > If we're > > going > to > > do that, we might as well switch 225-238/8 to unicast too -- only > > 224/8 > and > > 239/8 see much use in the (miniscule) multicast world, and the > exceedingly > > few oddballs using 225-238/8 could migrate to the remaining two /8s > > with minimal hassle. > > There is danger in the assumption that there is a > "(miniscule) multicast world". Whereas this is likely true > on the Big-I Internet, multicast is widely used in the > corporate manufacturing world. Who is prepared to pay the > price of lost connectivity when traditional multicast IP's > are suddenly deployed as end-user IP's? Who will be > modifying all my legacy system's IP stacks? > > I'm afraid I don't have much to offer in the way of > solutions... I simply call for caution when making > assumptions of what is actually "used" re: RFC1918 and multicast IP's. > > danT > > =================================================== > Dan Thorson - Seagate Technology - CCIE 10754 > desk +1 (952) 402-8293 fax +1 (952) 402-1007 > SeaTel 8-402-8293 =================================================== > > > > _______________________________________________ > 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 Thu May 17 12:44:33 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 17 May 2007 11:44:33 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing References: Message-ID: <016001c798a4$ea8fce60$453816ac@atlanta.polycom.com> Thus spake >> 255/8 is tough to unreserve in practice for the same reasons >> as 0/8 and 127/8, so it's probably not 240/4 but rather 240- >> 254/8. If we're going to do that, we might as well switch 225- >> 238/8 to unicast too -- only 224/8 and 239/8 see much use in >> the (miniscule) multicast world, and the exceedingly few >> oddballs using 225-238/8 could migrate to the remaining two >> /8s with minimal hassle. > > There is danger in the assumption that there is a "(miniscule) > multicast world". Whereas this is likely true on the Big-I Internet, > multicast is widely used in the corporate manufacturing world. I'm aware of that; I've deployed plenty of it myself for IP/TV and stock trading systems. However, _all_ of the registrations for public multicast use are in 224/8, and anyone using multicast privately should be in 239/8. I excluded both of those blocks. I now see that 232/8 and 233/8 are assigned (I'd forgotten SSM and GLOP), so remove those from my list as well. 225-231/8 and 234-238/8 are still completely reserved and nobody should be using them; if folks are, they'll deserve whatever problems they have -- just like folks who randomly chose reserved unicast addresses got burned when those addresses were later assigned. There's one particularly famous case of that (Apple, IIRC). > Who is prepared to pay the price of lost connectivity when > traditional multicast IP's are suddenly deployed as end-user > IP's? Who will be modifying all my legacy system's IP > stacks? Ditto for the arguments in favor of defining 240/4 to be unicast. It's either workable enough of an idea that we could deploy it in general use before v4 is otherwise exhausted, or it's so unworkable that it's not even worth standardizing for private use. Private networks already have vast v4 space available, both unicast and multicast, and if they're greenfields they can use v6 and get a virtually unlimited amount of space. My proposal for repurposing multicast space was more of a reductio ad absurdum argument, hence my reference to publication on 1 Apr. I should have made it clearer. 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 fergdawg at netzero.net Thu May 17 13:19:42 2007 From: fergdawg at netzero.net (Fergie) Date: Thu, 17 May 2007 17:19:42 GMT Subject: [ppml] Policy Proposal: IPv4 Soft Landing Message-ID: <20070517.101955.751.1397202@webmail16.lax.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Dan.Thorson at seagate.com wrote: >Those of us in the corporate world use significant portions of the 172.16 >/12, as well as 10/8 and 192.168/16. RFC1918 needs to be sacred ground. Absolutely, positively, violently agree. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) wj8DBQFGTI6qq1pz9mNUZTMRAv6AAKDGKQL2+HT5iqzO20ISpo2pVGNZUgCg5Dfh tIcaD8i5aShsvLBn/iSjAIs= =WQbE -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From randy at psg.com Thu May 17 13:39:12 2007 From: randy at psg.com (Randy Bush) Date: Thu, 17 May 2007 07:39:12 -1000 Subject: [ppml] getting converts to V6 In-Reply-To: <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <24899.1179347659@sa.vix.com> <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> Message-ID: <464C9340.6010105@psg.com> David Conrad wrote: > On May 16, 2007, at 3:34 PM, Paul Vixie wrote: >> been there, done that, got the t-shirt. (A6 and DNAME.) > A t-shirt would likely have worked better in supporting renumbering > than A6 and DNAME... bingo! award this boy both ears and the tail. > Sorry, what problem? I've been told "just build bigger routers" and take two asprin. right. > It is difficult for me to envision a future where there will be any > significant change to IPv6 architecture that might permit realistic > site-wide renumbering. But we have time yet... the man who jumped off a five story building was heard to say, as he passed the second floor, "so far so good". -- "the magnificent seven" (i think) randy From Thys at Zinpro.com Thu May 17 14:24:29 2007 From: Thys at Zinpro.com (COETZEE, Thys) Date: Thu, 17 May 2007 13:24:29 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <20070517.101955.751.1397202@webmail16.lax.untd.com> References: <20070517.101955.751.1397202@webmail16.lax.untd.com> Message-ID: >> >Those of us in the corporate world use significant portions of the 172.16 >> >/12, as well as 10/8 and 192.168/16. RFC1918 needs to be sacred ground. >> >> Absolutely, positively, violently agree. >> >> - - ferg Dang skippy! Keep up the good work folks. _________________________________________________________________ Thys Coetzee Director of Information Technology email: thys at zinpro.com Zinpro Performance Minerals???????? tel : 952-983-4000 10400 Viking Drive, Ste 240,??????? help: 952-983-3911 Eden Prairie,? MN? 55344? USA?????? www.zinpro.com _________________________________________________________________ -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Fergie Sent: Thursday, May 17, 2007 12:20 PM To: Dan.Thorson at seagate.com Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Dan.Thorson at seagate.com wrote: >Those of us in the corporate world use significant portions of the 172.16 >/12, as well as 10/8 and 192.168/16. RFC1918 needs to be sacred ground. Absolutely, positively, violently agree. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) wj8DBQFGTI6qq1pz9mNUZTMRAv6AAKDGKQL2+HT5iqzO20ISpo2pVGNZUgCg5Dfh tIcaD8i5aShsvLBn/iSjAIs= =WQbE -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ 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 Thu May 17 16:41:49 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 17 May 2007 16:41:49 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <464C801D.9040201@bogus.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <24899.1179347659@sa.vix.com> <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> <59C0DA2C-5032-400A-83C4-EBA919D5B1CE@delong.com> <464C801D.9040201@bogus.com> Message-ID: <6A6F6A08-CF27-446C-8CAC-B3C1ABE003EB@virtualized.org> Hi, On May 17, 2007, at 11:17 AM, Joel Jaeggli wrote: > The big drivers in dfz fib growth are the deaggregation and allocation > of v4 address space. I don't see deaggregation of ipv4 space stopping > after the rir's had out the last /24. My assumption is that it is going to get _MUCH_ worse. There is a lot of v4 address space allocated but not routed. I suspect that the unrouted IPv4 space will begin to start showing up when people begin to realize that it is worth something to somebody. The obvious implication of this is that you're going to see longer and longer prefixes being deaggregated out of what's in the routing tables today. > The biggest driver in fib growth > inside isp's isn't the DFZ in many cases, it's revenue producing > services like 2547 vpn's. ipv6 fib growth isn't even on the radar. Yep. I've been told there are ISPs out there that already are dealing with > 500K routes and are seeing convergence issues. And when these ISPs go to their vendors and ask for the roadmap for hardware, the upgrade deployment cycle outstrips the hardware development cycle. However, maybe the folk from those ISPs were exaggerating... (hard for me to tell) Rgds, -drc From drc at virtualized.org Thu May 17 23:41:34 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 17 May 2007 23:41:34 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> <4CE80DC9-D80D-4F74-A2F1-932AF92BE810@virtualized.org> Message-ID: <349C60CE-7F16-4474-9CB6-5A52DA9197BF@virtualized.org> Rich, On May 17, 2007, at 9:39 AM, Rich Emmings wrote: >> Hmm. I'm curious what you see as the idea that was poorly >> conceived in >> 2007-12 and weren't addressed in Soft Landing. > Creation of artificially early dates for restriction to resources will > increase demand for those resources earlier. "Soft Landing" does not impose dates. > I think the existing ARIN policies have done a great job at > encouraging those who can start, to start, but you can't push a rope [examples of why deploying IPv6 today is hard] If you read the proposal, you'll see that requirements to demonstrate IPv6 services and connectivity don't come into play until phase 2 or 3 which don't take effect until there are only 30 /8s and 20 /8s respectively left in the IANA free pool. Prior to this, ISPs requesting IPv4 space would need to document their plans to deploy IPv6. The point of this is to get people to start seriously thinking about deploying IPv6. >> Fortunately(?), IPv4 space scarcity isn't artificial. > But pushing up the date when we limit assignments is artificial > exhaustion. As stated previously, "Soft Landing" doesn't have dates, it has thresholds tied to the amount of space available in the IANA free pool. It tries to provide a smooth transition from "IPv4 available from the free pool" to "IPv4 unavailable from the free pool" by encouraging increased v4 efficiency and v6 deployment. > Call it hoarding, or call rationing, but it's artificial. Rationing is one approach to managing scarcity on the supply side. Hoarding is an approach on the demand side. Yes, it is artificial in the sense that it is imposed by people in reaction to the stimulus of unavailability of resource. The alternative is to pretend IPv4 isn't scarce. I'm not sure the Ostrich approach will benefit anyone, even if it were feasible. Rgds, -drc From randy at psg.com Thu May 17 23:49:32 2007 From: randy at psg.com (Randy Bush) Date: Thu, 17 May 2007 17:49:32 -1000 Subject: [ppml] getting converts to V6 In-Reply-To: <6A6F6A08-CF27-446C-8CAC-B3C1ABE003EB@virtualized.org> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <24899.1179347659@sa.vix.com> <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> <59C0DA2C-5032-400A-83C4-EBA919D5B1CE@delong.com> <464C801D.9040201@bogus.com> <6A6F6A08-CF27-446C-8CAC-B3C1ABE003EB@virtualized.org> Message-ID: <464D224C.2050300@psg.com> > Yep. I've been told there are ISPs out there that already are > dealing with > 500K routes and are seeing convergence issues. And > when these ISPs go to their vendors and ask for the roadmap for > hardware, the upgrade deployment cycle outstrips the hardware > development cycle. funny. just last week, the big two router vendors stood in front of us at ripe and said two million prefixes today and ten million in a few years. randy From drc at virtualized.org Fri May 18 00:43:46 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 18 May 2007 00:43:46 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <464D224C.2050300@psg.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <24899.1179347659@sa.vix.com> <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> <59C0DA2C-5032-400A-83C4-EBA919D5B1CE@delong.com> <464C801D.9040201@bogus.com> <6A6F6A08-CF27-446C-8CAC-B3C1ABE003EB@virtualized.org> <464D224C.2050300@psg.com> Message-ID: <7C045EAC-4F5C-4F00-A0FE-7D8999A51443@virtualized.org> On May 17, 2007, at 11:49 PM, Randy Bush wrote: >> Yep. I've been told there are ISPs out there that already are >> dealing with > 500K routes and are seeing convergence issues. And >> when these ISPs go to their vendors and ask for the roadmap for >> hardware, the upgrade deployment cycle outstrips the hardware >> development cycle. > > funny. just last week, the big two router vendors stood in front > of us at > ripe and said two million prefixes today and ten million in a few > years. I've seen one of those presentations (although I was not at RIPE). I will admit some confusion. Perhaps the ISP folks aren't talking to the right folks in the router vendors? After all, the market for 2M prefixes is really, really small so your general sales droid most likely won't know about the full details... Or perhaps the ISP folk were simply exaggerating? In any event, routing problem solved: just flat route everything. Makes lots of things much easier. Never need to renumber. You get mobility for free (without doing stupid backhaul tricks). Multi- homing is mostly trivial (still have to know BGP, but there are books for that). No need to fix the routing architecture. No need to re- deploy existing IPv6 stacks. No need to worry: crunch all you want, the router vendors will make more. Would that other things in life were this easy. Rgds, -drc From fergdawg at netzero.net Fri May 18 01:59:25 2007 From: fergdawg at netzero.net (Fergie) Date: Fri, 18 May 2007 05:59:25 GMT Subject: [ppml] getting converts to V6 Message-ID: <20070517.225939.754.1397249@webmail01.lax.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Randy Bush wrote: >> Yep. I've been told there are ISPs out there that already are >> dealing with > 500K routes and are seeing convergence issues. And >> when these ISPs go to their vendors and ask for the roadmap for >> hardware, the upgrade deployment cycle outstrips the hardware >> development cycle. > >funny. just last week, the big two router vendors stood in front of us at >ripe and said two million prefixes today and ten million in a few years. > That _is_ funny. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) wj8DBQFGTUC5q1pz9mNUZTMRAsRYAKDYsxznLRJ70S3RfJ09Mhko4PQ17gCdFjc1 K4gsWUBSWUuqXW9m5u+iFbg= =luW7 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From info at arin.net Fri May 18 10:16:35 2007 From: info at arin.net (Member Services) Date: Fri, 18 May 2007 10:16:35 -0400 Subject: [ppml] Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User Message-ID: <464DB543.1010107@arin.net> On 17 May 2007 the ARIN Advisory Council (AC) concluded its review of "Removal of ISP Immediate Need from End-User" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_13.html All persons in the community are encouraged to discuss Policy Proposal 2007-13 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-13 Removal of ISP Immediate Need from End-User Author: Rob Seastrom, David Williamson, Owen DeLong Proposal Version: 0.1 Submission Date: 4/24/07 Proposal type: delete Policy term: permanent Policy statement: Delete section 4.3.4, which reads: 4.3.4. Additional considerations End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4]. from the NRPM. Rationale: As discussed at ARIN XIX, section 4.3.4 creates a conflict with section 4.2.1.6 in that section 4.2.1.6 specifically excludes end users while section 4.3.4 is specifically for end users. Prior to the development of the multihoming policy for end users, the immediate need policy was required in order to support end users being able to get address space under some circumstances. The "immediate need" title is a misnomer as it is more an issue of "initial need without prior address utilization" than "immediate need". Such initial needs for end users are now addressed best through the multihoming policy. Timetable for implementation: immediate From info at arin.net Fri May 18 10:16:54 2007 From: info at arin.net (Member Services) Date: Fri, 18 May 2007 10:16:54 -0400 Subject: [ppml] Policy Proposal: Reclamation of Number Resources In-Reply-To: <463790E7.7040807@arin.net> References: <463790E7.7040807@arin.net> Message-ID: <464DB556.7090600@arin.net> On 17 May 2007 the ARIN Advisory Council (AC) reviewed "Reclamation of Number Resources" and did not accept it at this time as a formal policy proposal. The AC will work with the author prior to taking further action. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following policy proposal. 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 > > > _______________________________________________ > 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 info at arin.net Fri May 18 10:17:18 2007 From: info at arin.net (Member Services) Date: Fri, 18 May 2007 10:17:18 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464425E7.1070305@arin.net> References: <464425E7.1070305@arin.net> Message-ID: <464DB56E.7030101@arin.net> On 17 May 2007 the ARIN Advisory Council (AC) reviewed "IPv4 Soft Landing" and did not accept it at this time as a formal policy proposal. The AC will work with the author prior to taking further action. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The 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 iljitsch at muada.com Fri May 18 10:50:33 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 18 May 2007 16:50:33 +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: <6F7CE7B0-6413-482C-9EE0-C38BD0FF7999@muada.com> On 14-mei-2007, at 21:42, John Paul Morrison wrote: > If ARIN is going to do something to replace IPv4 with IPv6 Half-serious: ARIN could make its website IPv6-only. That would drive a minimum level of IPv6 adoption among ISPs... From iljitsch at muada.com Fri May 18 11:15:50 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 18 May 2007 17:15:50 +0200 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464425E7.1070305@arin.net> References: <464425E7.1070305@arin.net> Message-ID: <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> On 11-mei-2007, at 10:14, Member Services wrote: > 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 The effect of a policy like this is that: a. IPv4 becomes more painful to use because addresses are harder to get b. the incentive to move to IPv6 is reduced because the moment that the IPv4 is completely depleted is postponed c. in many cases, the same amount of address space as before is given out, but now as many small blocks, increasing the ARIN workload and hindering route aggregation As such, a policy like this doesn't seem to be in the best interest of the internet community at large. > Phase 1 > Threshold 40 /8s This will almost certainly happen within a year, with about 25% of the IPv4 address space or around a billion addresses still unused. Don't forget that in addition to what's available in the IANA global pool, there is also a lot of address space still available but held by the RIRs. Currently, about 24 /8s worth. From william at elan.net Fri May 18 12:39:29 2007 From: william at elan.net (william(at)elan.net) Date: Fri, 18 May 2007 09:39:29 -0700 (PDT) Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> Message-ID: I think having a policy that says that after certain time (in fact I'd prefer it to be specified as a year rather then IPv4 depletion thereshold), ISPs MUST demonstrate availability of IPv6 infrastructure before getting new ipv4 space is in fact good for IPv6 deployment and its production use which is ultimate goal here. I'd be interested in seeting "deploy IPv6" policy proposal that goes along those lines (even thinking about writing one based on some lines in David Conrad's proposal, but first want to see where that goes). On Fri, 18 May 2007, Iljitsch van Beijnum wrote: > On 11-mei-2007, at 10:14, Member Services wrote: > >> 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 > > The effect of a policy like this is that: > > a. IPv4 becomes more painful to use because addresses are harder to get > b. the incentive to move to IPv6 is reduced because the moment that the > IPv4 is completely depleted is postponed > c. in many cases, the same amount of address space as before is given > out, > but now as many small blocks, increasing the ARIN workload and > hindering > route aggregation > > As such, a policy like this doesn't seem to be in the best interest > of the internet community at large. > >> Phase 1 >> Threshold 40 /8s > > This will almost certainly happen within a year, with about 25% of > the IPv4 address space or around a billion addresses still unused. > Don't forget that in addition to what's available in the IANA global > pool, there is also a lot of address space still available but held > by the RIRs. Currently, about 24 /8s worth. > _______________________________________________ > 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 Fri May 18 12:07:44 2007 From: randy at psg.com (Randy Bush) Date: Fri, 18 May 2007 06:07:44 -1000 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> Message-ID: <464DCF50.3030700@psg.com> > I think having a policy that says that after certain time (in fact > I'd prefer it to be specified as a year rather then IPv4 depletion > thereshold), ISPs MUST demonstrate availability of IPv6 infrastructure > before getting new ipv4 space is in fact good for IPv6 deployment > and its production use which is ultimate goal here. that is the ultimate goal? if ipv6 is the members' futures (and that is yet to be clear) then if they choose to be foolish enough not to prepare, why is it incumbent on arin to *force* them to what we thing is a good business model? our charter is stewardship and education, not forcing members' business plans. randy From Lee.Howard at stanleyassociates.com Fri May 18 12:38:06 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 18 May 2007 12:38:06 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <4649FB0A.6030304@Dilkie.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Lee Dilkie > Sent: Tuesday, May 15, 2007 2:25 PM > I can also see you throw the "justify" and "need" words > about. The plain truth is this.. You "need" to move people > over to IPv6. They are not going to go willingly unless you > can offset the cost. The "need" is *yours*, not theirs. The > cost should also be *yours*. (and lets be honest, there is no > real cost to assigning a number). Pronoun trouble. Who are "you" and "they"? Cost of assigning a number includes the time to evaluate the request, time to record it, and maintenance of the recording system, not to mention infrastructure around it. Lee > -lee > > _______________________________________________ > 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 18 12:48:59 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 18 May 2007 17:48:59 +0100 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net><30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> Message-ID: > I think having a policy that says that after certain time (in > fact I'd prefer it to be specified as a year rather then IPv4 > depletion thereshold), ISPs MUST demonstrate availability of > IPv6 infrastructure before getting new ipv4 space is in fact > good for IPv6 deployment and its production use which is > ultimate goal here. I would prefer to see a new policy that says effective immediately, all applications for assignments or allocations must include the answers to a set of questions about the organization's preparations for IPv6. This is not an arduous requirement because it doesn't force the applicant to do anything more than research information internally and report it to ARIN. This is the kind of thing that the contacts already do. But it does raise the awareness of IPv6 inside these organizations because the questions are being asked. I haven't specified the exact questions because this is not a formal proposal. But I would think that they should be the type of questions that are meaningful for reporting statistics about IPv6 planning. Ideally, the author of the questions would seek some assistance from a university department (sociology, economics) to help structure the questions so that the statistics can detect movement through stages getting closer to a fully-functional network service. These types of statistics would be invaluable to show us the true state of IPv6 activity in North America. It may not be as far away as you think. And the very fact that we collect and publish such statistics helps raise public awareness of the address exhaustion issue without mandating any particular action. Through increased awareness we will get a better sense of what actions the industry would support ARIN in. And we should be able to do all of this independent of the other RIRs. The fact that there is a particular set of statistics being collected by all RIRs in a coordinated way, does not preclude ARIN from collecting or publishing some of its own stats. I made a suggestion that ARIN should provide regular (maybe monthly) reports of the IPv6 uptake among orgs with IPv4 allocations and assignments. That got rejected because it was too hard to coordinate with RIPE et al. which is irrelevant since I suggested that ARIN do this to shed some light on the North American situation. --Michael Dillon From Kavalec at BSWA.com Fri May 18 13:52:40 2007 From: Kavalec at BSWA.com (G. Waleed Kavalec) Date: Fri, 18 May 2007 11:52:40 -0600 Subject: [ppml] Policy Proposal: IPv4 Soft Landing Message-ID: > > ISPs MUST demonstrate availability of IPv6 infrastructure > > before getting new ipv4 space is in fact good for IPv6 deployment > > and its production use which is ultimate goal here. > that is the ultimate goal? > > if ipv6 is the members' futures (and that is yet to be clear) then if > they choose to be foolish enough not to prepare, why is it incumbent > on arin to *force* them to what we thing is a good business model? > our charter is stewardship and education, not forcing members' > siness plans. ARIN stewards resources. Exactly the reason. Why should those who ARE preparing for ipv6 be denuded of the last vestiges of ipv4 by the short-sightedness (or greed) of those who are not? > if ipv6 is the members' futures (and that is yet to be clear) What part of no more ipv4 to allocate is unclear? From michael.dillon at bt.com Fri May 18 12:56:45 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 18 May 2007 17:56:45 +0100 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: > Why should those who ARE preparing for ipv6 be denuded of the > last vestiges of ipv4 by the short-sightedness (or greed) of > those who are not? Because ARIN policy is made by finding the will of the majority and if the majority are shortsighted, we just have to live with that. Of course, if you can arrange for the majority to be longsighted through publicity and education, then you have solved this particular problem. --Michael Dillon From Yves.Poppe at vsnlinternational.com Fri May 18 12:58:23 2007 From: Yves.Poppe at vsnlinternational.com (Yves Poppe) Date: Fri, 18 May 2007 12:58:23 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <349C60CE-7F16-4474-9CB6-5A52DA9197BF@virtualized.org> Message-ID: In fact even 2007-12 didn't really impose any dates; it only only defines tresholds and a time interval. An A-date and a T-date. The A-date corresponds to a critical level of 30 remaining /8's. The two year interval to T-date corresponds to a second treshold defined as 10 /8's . The two years, if I read correctly, were derived from the current rate of consumption. There is even a provision to adapt that two year interval if the existing consumption rate varies. There is some futility to this debate as no one set any absolute dates, let alone artificial ones. Of course one might dispute if 30 and 10 are the correct tresholds to consider. All depends on how soft one wants to land. Myself, for one, I normally like to see the beginning of the runway and how long it is before crashing into something at the end. let's move on and admit that the upcoming scarcity and transition to a new IP address food supply needs to be managed if we want the transition to be orderly and riot free. Yves -----Message d'origine----- De : ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]De la part de David Conrad Envoy? : Thursday, May 17, 2007 11:42 PM ? : Rich Emmings Cc : ppml at arin.net Objet : Re: [ppml] Policy Proposal: IPv4 Soft Landing Rich, On May 17, 2007, at 9:39 AM, Rich Emmings wrote: >> Hmm. I'm curious what you see as the idea that was poorly >> conceived in >> 2007-12 and weren't addressed in Soft Landing. > Creation of artificially early dates for restriction to resources will > increase demand for those resources earlier. "Soft Landing" does not impose dates. > I think the existing ARIN policies have done a great job at > encouraging those who can start, to start, but you can't push a rope [examples of why deploying IPv6 today is hard] If you read the proposal, you'll see that requirements to demonstrate IPv6 services and connectivity don't come into play until phase 2 or 3 which don't take effect until there are only 30 /8s and 20 /8s respectively left in the IANA free pool. Prior to this, ISPs requesting IPv4 space would need to document their plans to deploy IPv6. The point of this is to get people to start seriously thinking about deploying IPv6. >> Fortunately(?), IPv4 space scarcity isn't artificial. > But pushing up the date when we limit assignments is artificial > exhaustion. As stated previously, "Soft Landing" doesn't have dates, it has thresholds tied to the amount of space available in the IANA free pool. It tries to provide a smooth transition from "IPv4 available from the free pool" to "IPv4 unavailable from the free pool" by encouraging increased v4 efficiency and v6 deployment. > Call it hoarding, or call rationing, but it's artificial. Rationing is one approach to managing scarcity on the supply side. Hoarding is an approach on the demand side. Yes, it is artificial in the sense that it is imposed by people in reaction to the stimulus of unavailability of resource. The alternative is to pretend IPv4 isn't scarce. I'm not sure the Ostrich approach will benefit anyone, even if it were feasible. 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 sleibrand at internap.com Fri May 18 13:19:35 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 18 May 2007 10:19:35 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> Message-ID: <464DE027.5000000@internap.com> Iljitsch van Beijnum wrote: > On 11-mei-2007, at 10:14, Member Services wrote: > >> 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 >> > > The effect of a policy like this is that: > > a. IPv4 becomes more painful to use because addresses are harder to get > b. the incentive to move to IPv6 is reduced because the moment that the > IPv4 is completely depleted is postponed > As written, those two statements appear to contradict each other. To put it in economic terms, the effect of a policy like this is that: * IPv4 becomes more expensive (though additional work required) because addresses are harder to get * as the cost of IPv4 growth goes up, IPv6 will become a cheaper/easier alternative for a number of orgs (for some earlier than others) * as some orgs switch their growth over to IPv6, the moment that IPv4 is completely depleted is postponed. This delays the increase in IPv4 cost (through slower triggering of IPv4 Soft Landing thresholds), and allows more time for the cost of deploying IPv6 services to come down (through natural replacement of old IPv4-only gear with new IPv6-capable gear, and by giving people time to learn IPv6) To re-use a recently proposed analogy, let's say that 5 years from now a major war starts in the Middle East, and a good majority of the oil extraction infrastructure is destroyed.. The US has to decide how to use the Strategic Petroleum Reserve (SPR) in order to minimize economic disruption while consumers switch to alternatives, such as transit, telecommuting, biofuels, the use of plug-in hybrids (PHEVs), and producers ramp up production from more expensive sources. Two strategies are proposed. In the first, the government proposes to release oil from the SPR (under today's replenish-it-later terms) to any refiner who needs it until the SPR is exhausted. In the second, they set thresholds for gradually increasing the price of oil from the SPR as the reserve is used up. In the first scenario, which I believe is analogous to leaving IPv4 allocation policies unchanged until the free pool is exhausted, you would see the following: * Much ado would be made about the need to make PHEVs, flex-fuel vehicles, and biofuels more available, and to encourage their use. Car-makers (vendors) would be encouraged to design and start producing PHEVs and flex-fuel vehicles, and some consumers would start buying them right away. The price of gas would go up, and consumers would start to change their behavior, but gasoline would still be available for several months, so many consumers who can still afford gas continue to take advantage of the now-less-congested roadways and drive to work as before. Biofuel producers would attempt to ramp up production capacity, but would initially be competing with fuel produced from the oil in the SPR * As the SPR is exhausted, there would be increasingly frantic discussion about the need for people to prepare for the impending shortage. This would encourage some additional consumers to start changing their behavior, but other consumers ignore the lectures and continue on as before. * Once the SPR is exhausted, gas prices shoot through the roof, and shortages start to be seen at gas stations. The consumers who have continued relying on their traditional automobiles suddenly realize they have to do something, and frantically start trying to change their behavior. In the second scenario, which I believe is analogous to the IPv4 Soft Landing proposal (or a similar policy), you would see the following: * The same calls for PHEVs, biofuels, etc. would be made. The price of petroleum-based fuels would start to rise more rapidly than under the first scenario, as oil from the SPR becomes more costly. * The biofuel producers would quickly find that they have a cost advantage over petroleum fuel, and would invest more rapidly in increasing production. Auto makers would see their sales switch over to nearly 100% PHEVs and flex-fuel vehicles, so they would ramp up PHEV production much faster, and convert all their other factories to producing flex-fuel vehicles. Mass transit providers would see their ridership rapidly increase, and would rapidly start adding buses and trains to their existing fleets. * As consumers switch away from petroleum-based fuels, the exhaustion of the SPR would slow. Eventually oil prices would settle to a new higher equilibrium, and the SPR probably would not be exhausted completely. Shortages of gas would be rare. * Some would argue that the government should've released more oil from the SPR to reduce the impact of the switch away from oil, but others would recognize that by applying the "Soft Landing" policy, major disruptions and shortages were averted, and the switch away from oil was accomplished at a much lower cost to the economy than originally predicted. (For other examples of that, see the results of the sulfur dioxide cap-and-trade program.) > c. in many cases, the same amount of address space as before is given > out, > but now as many small blocks, increasing the ARIN workload and > hindering > route aggregation > This is a different concern that we'll need to keep an eye on and possibly address. I'm not sure the deaggregation under Soft Landing would be any worse than that under a Hard Landing. As mentioned by others, we are likely to see a lot of deaggregation of existing allocated-but-unrouted space as exhaustion nears. It's possible that Soft Landing may reduce that, offsetting the additional routing table load from smaller allocations. > As such, a policy like this doesn't seem to be in the best interest > of the internet community at large. > As you can tell, I think that a policy like Soft Landing that attempts to provide incentives for people to gradually move their growth away from IPv4 will help ease the disruption of the transition. As such, I believe that a proposal like Soft Landing is much better than the alternative of continuing existing policy until the unallocated IPv4 pool is exhausted. -Scott From jmorrison at bogomips.com Fri May 18 14:29:39 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Fri, 18 May 2007 11:29:39 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <59C0DA2C-5032-400A-83C4-EBA919D5B1CE@delong.com> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <24899.1179347659@sa.vix.com> <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> <59C0DA2C-5032-400A-83C4-EBA919D5B1CE@delong.com> Message-ID: <464DF093.3080602@bogomips.com> This all gets at the question of "why must PI always be the answer?". At the beginning of the Internet, things worked well, but we soon found out the address space and routing weren't scalable. PI was the only thing around, and people allocated globally unique IP's to everything (hey, I might be able to afford a full time 9600 slip link to the 256kbps backbone so I can read netnews at home one day!). There's nothing wrong with those assumptions if it scales, which it didn't with IPv4 and the routers of the day. (The irony: I have my globally unique addresses and a lot more bandwidth, but the market has been so conditioned by lowered expectations and an un-even playing field that I can't route them for the price I'm willing to pay) The growth of the Internet was unprecedented and took everyone off guard. People made some bad decisions - look at the stock market bubble, and people made technical fixes to IPv4 and the routing architecture of the time. Some of those technical and policy decisions were justifiable to keep things going, but they lowered expectations. They created second-class net citizens. The quick fixes got us used to kludges and hacks to keep things working, and we're so used to second best that people ask "why must PI always be the answer?" IPv6 solved the address scalability problem. BGPv4 and Moore's law took the urgency off of the routing problem for IPv4, and hopefully IPv6 for a while. I make BGP and networks run for a living, I think routing scalability is still an issue, but I don't see the same sense of panic any more. People in the industry now expect the growth, so maybe they aren't as shocked by it any more. I don't know what the answer is, but I think there are more tools and people working on sensible solutions. Quoting from IETF 68 "5-10 years of growth" and "No need for panic" (they conclude there's no firm answer and more research required). I prefer to think that we'll just reach a plateau or natural limit on the Internet - and I hope in most areas as well - we live in a world with finite resources and humans with finite capabilities. We don't expect cars to double in speed every few years. Keyboards don't need to get new keys every generation etc. (keyboards will be replaced by something altogether before humans evolve extra (fewer?) digits!) Back to Policy: We have the luxury of being able to do the "Right Thing". We're not going to run out of (v6) addresses and the routing infrastructure is not going to collapse in six months or a year, so we don't need knee-jerk solutions. My impression is that we're on the right track with respect to PI in IPv6. I definitely don't think we should use the shortcomings of the current routing architecture to justify making any new bad or unfair policy decisions. Soft Landing: this proposal is reasonable in principle and it or something very much like it needs to be the roadmap for getting from IPv4 to v6. If this proposal doesn't gain consensus, then surely the consensus is "there is no policy on transitioning from IPv4 to IPv6". if that's the real consensus it would be nice to have it expressed. I would be happy to help construct such a policy, since it's a win either way. Heather Schiller wrote: > > So, why isn't your complaint that no one has built a good, reasonable, > easy method or tool for renumbering or developed an assignment scheme > or way of routing that would allow you to not have to renumber or > renumber entirely? There's more than one way to handle a problem. > Why must PI always be the answer? (because the other is harder? takes > more time? more collaboration? __?) Owen DeLong wrote: >>> in the IPng wars, many folks asserted that without a solution to the >>> routing problem, adding more address bits would both fail to solve >>> existing problems and also make existing problems worse and also cause >>> new problems. as you can see, those folks lost the war. ("too >>> little, >>> too soon." --tli) >> >> Sorry, what problem? I've been told "just build bigger routers" so >> many times now, maybe a million lemmings might not be wrong. >> > The lemmings are wrong. There is no feasible way to scale a routing > solution > that continues to overload the end system identifier and routing > locator onto > the same number. In the end, even the telcos have abandoned this idea, > and it is long past the time when IP should have in the IDR world. From jmorrison at bogomips.com Fri May 18 14:46:33 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Fri, 18 May 2007 11:46:33 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> Message-ID: <464DF489.7020006@bogomips.com> This is a great idea, and could certainly seed additional information or awareness, like the real world availability of v6 etc. michael.dillon at bt.com wrote: >> I think having a policy that says that after certain time (in >> fact I'd prefer it to be specified as a year rather then IPv4 >> depletion thereshold), ISPs MUST demonstrate availability of >> IPv6 infrastructure before getting new ipv4 space is in fact >> good for IPv6 deployment and its production use which is >> ultimate goal here. >> > > I would prefer to see a new policy that says effective immediately, all > applications for assignments or allocations must include the answers to > a set of questions about the organization's preparations for IPv6. This > is not an arduous requirement because it doesn't force the applicant to > do anything more than research information internally and report it to > ARIN. This is the kind of thing that the contacts already do. But it > does raise the awareness of IPv6 inside these organizations because the > questions are being asked. > > I haven't specified the exact questions because this is not a formal > proposal. But I would think that they should be the type of questions > that are meaningful for reporting statistics about IPv6 planning. > Ideally, the author of the questions would seek some assistance from a > university department (sociology, economics) to help structure the > questions so that the statistics can detect movement through stages > getting closer to a fully-functional network service. > > These types of statistics would be invaluable to show us the true state > of IPv6 activity in North America. It may not be as far away as you > think. And the very fact that we collect and publish such statistics > helps raise public awareness of the address exhaustion issue without > mandating any particular action. Through increased awareness we will get > a better sense of what actions the industry would support ARIN in. > > And we should be able to do all of this independent of the other RIRs. > The fact that there is a particular set of statistics being collected by > all RIRs in a coordinated way, does not preclude ARIN from collecting or > publishing some of its own stats. I made a suggestion that ARIN should > provide regular (maybe monthly) reports of the IPv6 uptake among orgs > with IPv4 allocations and assignments. That got rejected because it was > too hard to coordinate with RIPE et al. which is irrelevant since I > suggested that ARIN do this to shed some light on the North American > situation. > > --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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alh-ietf at tndh.net Fri May 18 16:51:35 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 18 May 2007 13:51:35 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464DE027.5000000@internap.com> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> <464DE027.5000000@internap.com> Message-ID: <0e6501c7998e$53068350$f91389f0$@net> Your analogies are fine, but try another one: We are on the space shuttle (no engines or means for a go-around) and the current glide slope is too steep to avoid a hard landing because there is not enough distance left (reserve pool) to the runway. All you can really do is brace for impact ... I am not opposed to an approach like soft-landing, but the markers have to recognize that consumption is accelerating. This is where 2007-12 failed, because it effectively built in an assumption of a close to flat 10 /8's per year. The trend says we will be below 40 /8's in the pool by the end of this year, and right at if not below 20 by the end of next year. Consider that there are effectively 30 months left, and then think about how much time people will need to respond before setting the thresholds. To a first order I would blow off the wait for 40, and just start requiring a plan now. Since we will be approaching 30 about a year from now, that might make sense as an 'implementation required' threshold; as either the pool depth or 7/1/08 whichever comes first. Beyond that there is very little that will make any difference, including reclamation or redefining 240/4. One might think about going for 'implementation required' starting at the end of this year, which would give close to 2 years of parallel run rate, but that would set off a short term panic because it does not leave time for a business plan response. To a first order I agree with Randy that it is not the RIR's job to force the members to be proactive. At the same time it is a reasonable part of stewardship to make sure the membership is informed so the inevitable claims about 'you didn't tell me' can be dealt with. In light of this, the message has to go out to everyone, not just those that are actively applying; so the past policy proposals appear to be short-sighted in that you only find out about the change when you come knocking for more. Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Scott Leibrand > Sent: Friday, May 18, 2007 10:20 AM > To: Iljitsch van Beijnum > Cc: ARIN PPML > Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing > > Iljitsch van Beijnum wrote: > > On 11-mei-2007, at 10:14, Member Services wrote: > > > >> 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 > >> > > > > The effect of a policy like this is that: > > > > a. IPv4 becomes more painful to use because addresses are harder to > get > > b. the incentive to move to IPv6 is reduced because the moment that > the > > IPv4 is completely depleted is postponed > > > As written, those two statements appear to contradict each other. To > put it in economic terms, the effect of a policy like this is that: > > * IPv4 becomes more expensive (though additional work required) > because addresses are harder to get > * as the cost of IPv4 growth goes up, IPv6 will become a > cheaper/easier alternative for a number of orgs (for some earlier > than others) > * as some orgs switch their growth over to IPv6, the moment that > IPv4 is completely depleted is postponed. This delays the > increase in IPv4 cost (through slower triggering of IPv4 Soft > Landing thresholds), and allows more time for the cost of > deploying IPv6 services to come down (through natural replacement > of old IPv4-only gear with new IPv6-capable gear, and by giving > people time to learn IPv6) > > To re-use a recently proposed analogy, let's say that 5 years from now a > major war starts in the Middle East, and a good majority of the oil > extraction infrastructure is destroyed.. The US has to decide how to > use the Strategic Petroleum Reserve (SPR) in order to minimize economic > disruption while consumers switch to alternatives, such as transit, > telecommuting, biofuels, the use of plug-in hybrids (PHEVs), and > producers ramp up production from more expensive sources. Two > strategies are proposed. In the first, the government proposes to > release oil from the SPR (under today's replenish-it-later terms) to any > refiner who needs it until the SPR is exhausted. In the second, they > set thresholds for gradually increasing the price of oil from the SPR as > the reserve is used up. > > In the first scenario, which I believe is analogous to leaving IPv4 > allocation policies unchanged until the free pool is exhausted, you > would see the following: > > * Much ado would be made about the need to make PHEVs, flex-fuel > vehicles, and biofuels more available, and to encourage their > use. Car-makers (vendors) would be encouraged to design and start > producing PHEVs and flex-fuel vehicles, and some consumers would > start buying them right away. The price of gas would go up, and > consumers would start to change their behavior, but gasoline would > still be available for several months, so many consumers who can > still afford gas continue to take advantage of the > now-less-congested roadways and drive to work as before. Biofuel > producers would attempt to ramp up production capacity, but would > initially be competing with fuel produced from the oil in the SPR > * As the SPR is exhausted, there would be increasingly frantic > discussion about the need for people to prepare for the impending > shortage. This would encourage some additional consumers to start > changing their behavior, but other consumers ignore the lectures > and continue on as before. > * Once the SPR is exhausted, gas prices shoot through the roof, and > shortages start to be seen at gas stations. The consumers who > have continued relying on their traditional automobiles suddenly > realize they have to do something, and frantically start trying to > change their behavior. > > In the second scenario, which I believe is analogous to the IPv4 Soft > Landing proposal (or a similar policy), you would see the following: > > * The same calls for PHEVs, biofuels, etc. would be made. The price > of petroleum-based fuels would start to rise more rapidly than > under the first scenario, as oil from the SPR becomes more costly. > * The biofuel producers would quickly find that they have a cost > advantage over petroleum fuel, and would invest more rapidly in > increasing production. Auto makers would see their sales switch > over to nearly 100% PHEVs and flex-fuel vehicles, so they would > ramp up PHEV production much faster, and convert all their other > factories to producing flex-fuel vehicles. Mass transit providers > would see their ridership rapidly increase, and would rapidly > start adding buses and trains to their existing fleets. > * As consumers switch away from petroleum-based fuels, the > exhaustion of the SPR would slow. Eventually oil prices would > settle to a new higher equilibrium, and the SPR probably would not > be exhausted completely. Shortages of gas would be rare. > * Some would argue that the government should've released more oil > from the SPR to reduce the impact of the switch away from oil, but > others would recognize that by applying the "Soft Landing" policy, > major disruptions and shortages were averted, and the switch away > from oil was accomplished at a much lower cost to the economy than > originally predicted. (For other examples of that, see the > results of the sulfur dioxide cap-and-trade program.) > > > > c. in many cases, the same amount of address space as before is given > > out, > > but now as many small blocks, increasing the ARIN workload and > > hindering > > route aggregation > > > This is a different concern that we'll need to keep an eye on and > possibly address. I'm not sure the deaggregation under Soft Landing > would be any worse than that under a Hard Landing. As mentioned by > others, we are likely to see a lot of deaggregation of existing > allocated-but-unrouted space as exhaustion nears. It's possible that > Soft Landing may reduce that, offsetting the additional routing table > load from smaller allocations. > > As such, a policy like this doesn't seem to be in the best interest > > of the internet community at large. > > > As you can tell, I think that a policy like Soft Landing that attempts > to provide incentives for people to gradually move their growth away > from IPv4 will help ease the disruption of the transition. As such, I > believe that a proposal like Soft Landing is much better than the > alternative of continuing existing policy until the unallocated IPv4 > pool is exhausted. > > > -Scott > _______________________________________________ > 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 jeroen at unfix.org Fri May 18 17:01:33 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 18 May 2007 22:01:33 +0100 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <0e6501c7998e$53068350$f91389f0$@net> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> <464DE027.5000000@internap.com> <0e6501c7998e$53068350$f91389f0$@net> Message-ID: <464E142D.3000909@spaghetti.zurich.ibm.com> Tony Hain wrote: [.. well said piece of text ..] > To a first order I agree with Randy that it is not the RIR's job to force > the members to be proactive. At the same time it is a reasonable part of > stewardship to make sure the membership is informed so the inevitable claims > about 'you didn't tell me' can be dealt with. In light of this, the message > has to go out to everyone, not just those that are actively applying; so the > past policy proposals appear to be short-sighted in that you only find out > about the change when you come knocking for more. Simple, ARIN has registered POCs, spam them, per email or snailmail. Even better, spam them, and let them fill in a form on the site saying that they know about it. This also verifies that the POC data is still valid. All in one go. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Fri May 18 17:01:27 2007 From: randy at psg.com (Randy Bush) Date: Fri, 18 May 2007 11:01:27 -1000 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <0e6501c7998e$53068350$f91389f0$@net> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> <464DE027.5000000@internap.com> <0e6501c7998e$53068350$f91389f0$@net> Message-ID: <464E1427.6080305@psg.com> > Your analogies are fine, but try another one: > We are on the space shuttle (no engines or means for a go-around) and the > current glide slope is too steep to avoid a hard landing because there is > not enough distance left (reserve pool) to the runway. All you can really do > is brace for impact ... not applicable. in fact, rather embarrassing hyperbole. the internet is not going to crash. there will be no news at 11. ipv4 space will slowly transition to a different model of distribution, where folk chop it finer, buy, sell, and trade, etc. you will still be able to get ipv4 space 20 years from now, just not as cheaply as you can now, just as we pay more now than we did 20 years ago. life goes on. so will the internet. we need to understand these changes, be prepared for them technically and in our business plans, etc. where we is both the users of the space and the registrars of the space such as arin. hence the work on certifying the rights to use resources. personally, i am more worried that the vendors are being a bit, shall we be polite and say, optimistic about their ability to converge with O(10^6|7) routes in the dfz than i am about not being able to get ipv4 space if i really need it. chicken little was wrong. randy From bicknell at ufp.org Fri May 18 17:15:08 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 18 May 2007 17:15:08 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <6A6F6A08-CF27-446C-8CAC-B3C1ABE003EB@virtualized.org> References: <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <24899.1179347659@sa.vix.com> <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> <59C0DA2C-5032-400A-83C4-EBA919D5B1CE@delong.com> <464C801D.9040201@bogus.com> <6A6F6A08-CF27-446C-8CAC-B3C1ABE003EB@virtualized.org> Message-ID: <20070518211508.GC37682@ussenterprise.ufp.org> In a message written on Thu, May 17, 2007 at 04:41:49PM -0400, David Conrad wrote: > > The biggest driver in fib growth > > inside isp's isn't the DFZ in many cases, it's revenue producing > > services like 2547 vpn's. ipv6 fib growth isn't even on the radar. > > Yep. I've been told there are ISPs out there that already are > dealing with > 500K routes and are seeing convergence issues. And > when these ISPs go to their vendors and ask for the roadmap for > hardware, the upgrade deployment cycle outstrips the hardware > development cycle. I've told this to people off list before, but it seems to be a repeat topic. At least one "major ISP" recently gave us a presentation on their 2547 VPN offering. As part of that, I asked them what limited they imposed on the number of routes (inside the VPN) and I was told 5,000 per site. We have 45 sites, so that could potentially be 225,000 prefixes just from one customer! Fortunately for them we're not that messy internally. Now, 2547 routes don't look like internet routes, and your core may not need to know about them, and all that. At the same time, it's hard to have a lot of sympathy for "my internet routing table is too big" when you're willing to put that much trash per customer into your routing table. -- 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 alh-ietf at tndh.net Fri May 18 17:17:24 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 18 May 2007 14:17:24 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <6A6F6A08-CF27-446C-8CAC-B3C1ABE003EB@virtualized.org> References: <4649F001.9020607@cjbsys.bdb.com> <4649F5BB.7070306@spaghetti.zurich.ibm.com> <4649FB0A.6030304@Dilkie.com> <6AE5318A-667E-41EB-9251-84FEFF976823@blighty.com> <464A05D2.3080309@Dilkie.com> <464A10F2.9070408@spaghetti.zurich.ibm.com> <3c3e3fca0705151552p1ffc4f2clca6643b5671ab0bf@mail.gmail.com> <464A42B3.201@spaghetti.zurich.ibm.com> <73394C3E0701EB4F8AAD37FCFF1BDF4CFFDF5A@email> <464B2256.4020101@spaghetti.zurich.ibm.com> <464B57E8.3070401@bogomips.com> <24899.1179347659@sa.vix.com> <5962AB01-AE84-4C7A-A1D9-8355DEF8EA7F@virtualized.org> <59C0DA2C-5032-400A-83C4-EBA919D5B1CE@delong.com> <464C801D.9040201@bogus.com> <6A6F6A08-CF27-446C-8CAC-B3C1ABE003EB@virtualized.org> Message-ID: <0e6f01c79991$ee080880$ca181980$@net> David Conrad wrote: > ... > > The biggest driver in fib growth > > inside isp's isn't the DFZ in many cases, it's revenue producing > > services like 2547 vpn's. ipv6 fib growth isn't even on the radar. > > Yep. I've been told there are ISPs out there that already are > dealing with > 500K routes and are seeing convergence issues. And > when these ISPs go to their vendors and ask for the roadmap for > hardware, the upgrade deployment cycle outstrips the hardware > development cycle. > > However, maybe the folk from those ISPs were exaggerating... (hard > for me to tell) It is more like the deployment cycle outstrips their budget. One would think that since the VPN's that are really causing the problem are revenue producing, there would be a feedback path to align growth with budgets. Then again one might think that large organizations had their internal act together and could even consider acting in a coordinated manner. ;) Tony From alh-ietf at tndh.net Fri May 18 17:30:27 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 18 May 2007 14:30:27 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <464E1427.6080305@psg.com> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> <464DE027.5000000@internap.com> <0e6501c7998e$53068350$f91389f0$@net> <464E1427.6080305@psg.com> Message-ID: <0e8901c79993$c14d0140$43e703c0$@net> Randy Bush wrote: > > Your analogies are fine, but try another one: > > We are on the space shuttle (no engines or means for a go-around) and > the > > current glide slope is too steep to avoid a hard landing because there > is > > not enough distance left (reserve pool) to the runway. All you can > really do > > is brace for impact ... > > not applicable. in fact, rather embarrassing hyperbole. the internet > is > not going to crash. there will be no news at 11. > > ipv4 space will slowly transition to a different model of distribution, > where folk chop it finer, buy, sell, and trade, etc. you will still be > able > to get ipv4 space 20 years from now, just not as cheaply as you can now, > just as we pay more now than we did 20 years ago. life goes on. so > will > the internet. > > we need to understand these changes, be prepared for them technically > and in > our business plans, etc. where we is both the users of the space and > the > registrars of the space such as arin. hence the work on certifying the > rights to use resources. > > personally, i am more worried that the vendors are being a bit, shall we > be > polite and say, optimistic about their ability to converge with > O(10^6|7) > routes in the dfz than i am about not being able to get ipv4 space if i > really need it. > > chicken little was wrong. I did not say that the Internet would end. What does end rather abruptly though is the wonderland where the RIRs are in any position to claim stewardship. Yes you will be able to get space on the open market, but what is your incentive to retain membership at ARIN and have to report back all the blocks you just acquired? Bottom line; where does ARIN funding come from in a world where addresses are traded on eBay? That actually raises the bogus point that keeps coming up from time to time, IPv6 addresses are not free despite claims to the contrary. Unless RIR membership became free and I didn't notice... ;) Tony From iljitsch at muada.com Fri May 18 17:34:55 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 18 May 2007 23:34:55 +0200 Subject: [ppml] Soft and hard landings, was: Re: Policy Proposal: IPv4 Soft Landing In-Reply-To: <464DE027.5000000@internap.com> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> <464DE027.5000000@internap.com> Message-ID: <6A10E8C8-D5E6-4948-A045-EC4FFF3B53EB@muada.com> On 18-mei-2007, at 19:19, Scott Leibrand wrote: >> The effect of a policy like this is that: >> a. IPv4 becomes more painful to use because addresses are harder >> to get >> b. the incentive to move to IPv6 is reduced because the moment >> that the >> IPv4 is completely depleted is postponed > As written, those two statements appear to contradict each other. > To put it in economic terms, You're right, they appear to contradict. But this isn't unheard of. For instance, any economist can tell you that raising prices can easily result in making less money. > the effect of a policy like this is that: > * IPv4 becomes more expensive (though additional work required) > because addresses are harder to get > * as the cost of IPv4 growth goes up, IPv6 will become a > cheaper/easier alternative for a number of orgs (for some earlier > than others) > * as some orgs switch their growth over to IPv6, the moment that > IPv4 is completely depleted is postponed. This delays the > increase in IPv4 cost (through slower triggering of IPv4 Soft > Landing thresholds), and allows more time for the cost of > deploying IPv6 services to come down (through natural replacement > of old IPv4-only gear with new IPv6-capable gear, and by giving > people time to learn IPv6) You only look at the cost part without considering the benefit. Apart from less tangible things like being a technology leader or being prepared, the benefit of adopting IPv6 is negligible: you can only reach a tiny part of the internet over IPv6: something in the order of 0.1%. So the cost difference between IPv4 and IPv6 can never drive IPv6 adoption. > To re-use a recently proposed analogy, let's say that 5 years from > now a major war starts in the Middle East, and a good majority of > the oil extraction infrastructure is destroyed.. The US has to > decide how to use the Strategic Petroleum Reserve (SPR) in order to > minimize economic disruption while consumers switch to alternatives [...] The problem with this analogy is that with oil, you need a constant supply to operate. With address space, once you have it, you're set, no need to come back for more. So a better analogy would be that once oil is no longer available, the switch to other power sources is seamless, but it's no longer possible to build new roads for lack of asphalt. Fortunately, there's still plenty of steel so in the alternative, it's possible to lay down tracks. The car manufacturers anticipated all of this and by now all models come with both regular tires for driving on roads and steel tire-less wheels for use on the tracks. The problem is that business etc are unwilling to spend the money to convert their parking lots to allow people to arrive over tracks and park their cars using the tracks system. This means that cities aren't going to install tracks because everyone keeps driving on roads, anyway. But now we are running out of asphalt. We can either use the reserve and keep building the roads we need today, even though we know we can only keep doing that for a few more years, or we can artificially restrict the availability of asphalt. In the latter case, it becomes increasingly difficult to build new roads, but since there is no track infrastructure to speak of, the only effect is that it costs more time and money to build less effective new roads. Although new roads now have fewer lanes than they really need, congestion is a problem, but you can still get everywhere by road and the remaining asphalt is going to last for a fairly long time so pretty much nobody bothers with tracks. The alternative is that the remaining asphalt is used up as per current needs, and soon it becomes clear that the supply is going to run out in the near future, so some people start installing tracks to be ready. When asphalt runs out, people still keep driving on the existing roads, but all new infrastructure can only be tracks and the transition from roads to tracks starts happening in earnest. > As you can tell, I think that a policy like Soft Landing that > attempts to provide incentives for people to gradually move their > growth away from IPv4 will help ease the disruption of the > transition. As such, I believe that a proposal like Soft Landing > is much better than the alternative of continuing existing policy > until the unallocated IPv4 pool is exhausted. The way I see it, the undeniable prospect of running out of IPv4 address space within two to four years is a prerequisite for any meaningful IPv6 adoption. It could very well be that the prospect of running out isn't even enough, and we actually have to run out before large numbers of internet users take notice. (In my most cynical moments I'm thinking lots of people won't care that the IPv4 club isn't admitting new members and aren't even going to bother adopting v6 when we're out of v4 space.) We're currently still in the situation where people can fool themselves into thinking that we're not going to run out of IPv4 space within the next decade or so, hence they don't have to take any action. Implementing any measures that postpone the moment of running out only give people more excuses to ignore IPv6. From randy at psg.com Fri May 18 17:42:13 2007 From: randy at psg.com (Randy Bush) Date: Fri, 18 May 2007 11:42:13 -1000 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <0e8901c79993$c14d0140$43e703c0$@net> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> <464DE027.5000000@internap.com> <0e6501c7998e$53068350$f91389f0$@net> <464E1427.6080305@psg.com> <0e8901c79993$c14d0140$43e703c0$@net> Message-ID: <464E1DB5.6000108@psg.com> Tony Hain wrote: > Randy Bush wrote: >>> Your analogies are fine, but try another one: We are on the space >>> shuttle (no engines or means for a go-around) and the current glide >>> slope is too steep to avoid a hard landing because there is not >>> enough distance left (reserve pool) to the runway. All you can really >>> do is brace for impact ... >> not applicable. in fact, rather embarrassing hyperbole. the internet >> is not going to crash. there will be no news at 11. >> >> ipv4 space will slowly transition to a different model of distribution, >> where folk chop it finer, buy, sell, and trade, etc. you will still >> be able to get ipv4 space 20 years from now, just not as cheaply as you >> can now, just as we pay more now than we did 20 years ago. life goes >> on. so will the internet. >> >> we need to understand these changes, be prepared for them technically >> and in our business plans, etc. where we is both the users of the >> space and the registrars of the space such as arin. hence the work on >> certifying the rights to use resources. >> >> personally, i am more worried that the vendors are being a bit, shall >> we be polite and say, optimistic about their ability to converge with >> O(10^6|7) routes in the dfz than i am about not being able to get ipv4 >> space if i really need it. >> >> chicken little was wrong. > > I did not say that the Internet would end. What does end rather abruptly > though is the wonderland where the RIRs are in any position to claim > stewardship. you may want to read your message again. > Yes you will be able to get space on the open market, but what is your > incentive to retain membership at ARIN and have to report back all the > blocks you just acquired? Bottom line; where does ARIN funding come from > in a world where addresses are traded on eBay? certification of title, in-addr.arpa, ... randy From jeroen at unfix.org Fri May 18 17:47:05 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 18 May 2007 22:47:05 +0100 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <0e8901c79993$c14d0140$43e703c0$@net> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> <464DE027.5000000@internap.com> <0e6501c7998e$53068350$f91389f0$@net> <464E1427.6080305@psg.com> <0e8901c79993$c14d0140$43e703c0$@net> Message-ID: <464E1ED9.20909@spaghetti.zurich.ibm.com> Tony Hain wrote: [..] > I did not say that the Internet would end. What does end rather abruptly > though is the wonderland where the RIRs are in any position to claim > stewardship. Yes you will be able to get space on the open market, but what > is your incentive to retain membership at ARIN and have to report back all > the blocks you just acquired? Bottom line; where does ARIN funding come from > in a world where addresses are traded on eBay? > > That actually raises the bogus point that keeps coming up from time to time, > IPv6 addresses are not free despite claims to the contrary. Unless RIR > membership became free and I didn't notice... ;) But that is the case anyway, when somebody like Google (just to name something) would pick 1337::/16 or 13.37.0.0/16 for their webservers I am pretty sure that a lot of ISP's will start accepting those routes to them, especially when the big G would give a 1000 EUR/month or other nice incentive (porsche per enabled person? :) It is more 'being nice' and 'playing nice' that keeps this going, nothing else. If RIR's want to keep their stewardship, which IMHO they should, they should as quickly as possible introduce BGP certificates or a similar mechanism that can be used by systems like S-BGP or BGP-S, that way, when a route gets transfered, the transfer must include the certificate. As these certificates are time-limited, they are forced to request the RIR for a new one. Of course, an alternate cert root or disabling the certs for certain routes can help to overcome that again. The good thing would be that you at least know for sure that the certs that you do accept and verify correctly, that they are really the ones they claim they are and not some s[cp]ammer somewhere. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From pekkas at netcore.fi Sat May 19 02:16:20 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 19 May 2007 09:16:20 +0300 (EEST) Subject: [ppml] routing certificate usefulness [Policy Proposal: IPv4 Soft Landing] In-Reply-To: <464E1ED9.20909@spaghetti.zurich.ibm.com> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> <464DE027.5000000@internap.com> <0e6501c7998e$53068350$f91389f0$@net> <464E1427.6080305@psg.com> <0e8901c79993$c14d0140$43e703c0$@net> <464E1ED9.20909@spaghetti.zurich.ibm.com> Message-ID: On Fri, 18 May 2007, Jeroen Massar wrote: ... > The good thing would be that you at least know for sure that the certs > that you do accept and verify correctly, that they are really the ones > they claim they are and not some s[cp]ammer somewhere. I'm not sure how that'd help most of the network operators in practice until a critical mass is reached. >From upstreams where you basically get a default route, there's little difference whether someone uses routing certificates as your traffic is going to go there in any case because 99.5% of networks won't use routing certificates. The good thing is that if your peers use routing certificates, their traffic cannot be hijacked by another peer or someone in the Internet. So, there's some incentive to deploy this for those who have a significant number of non-transit peers. In your own advertisements the main benefit seems to be that those folks that do verify routing certificates might be able to reject hijacked advertisements from someone else, but this isn't going to work very well until most of the networks in the middle would verify routing certificates. Given that the networks in the middle have established the business of forwarding whatever they're given and paid for, I'm not sure how interested they'd be to deploy s*BGP. Have I mised something ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Lee at Dilkie.com Sun May 20 16:44:07 2007 From: Lee at Dilkie.com (Lee Dilkie) Date: Sun, 20 May 2007 16:44:07 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> Message-ID: <4650B317.7090607@Dilkie.com> Howard, W. Lee wrote: >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of Lee Dilkie >> Sent: Tuesday, May 15, 2007 2:25 PM >> I can also see you throw the "justify" and "need" words >> about. The plain truth is this.. You "need" to move people >> over to IPv6. They are not going to go willingly unless you >> can offset the cost. The "need" is *yours*, not theirs. The >> cost should also be *yours*. (and lets be honest, there is no >> real cost to assigning a number). >> > > > Pronoun trouble. Who are "you" and "they"? > My bad. I forget that many on the list are not english speaking as a first language. "You" refers to producers of IP address space, in this case ARIN and ARIN's members, the ISPs. I'm not included in that list as I am not an ARIN member and as I've been made painfully aware, not entitled to making policy decisions. If I were an ARIN member, I would have used the term "we". "They" refers to the consumers of IP address space, the end customers for the most part. It's those folks who need to be convinced to make the move to IPv6. If all the dire predictions are true, the producers will be out of a job unless they can convince the consumers to switch to the new address space. Not unlike Microsoft's efforts to convince us that a new OS is a "must have" every few years.... As others have said (and my mechanical engineering prof first told me), you can't push a rope. You need to make it a compelling decision. Going about this like a typical government organization is not the way to reach your goals. Throwing up artificial costs is hardly a good start... > Cost of assigning a number includes the time to evaluate the > request, time to record it, and maintenance of the recording > system, not to mention infrastructure around it. > No offense. But the cost of assigning me a drivers license, including all the testing and whatnot, is *far* less than ARIN's fees. Someone is making a boatload of money here. Or wasting a boatload. Either way, my original statement stands. > Lee > > -lee From michael.dillon at bt.com Sun May 20 17:02:44 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 20 May 2007 22:02:44 +0100 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <0e6501c7998e$53068350$f91389f0$@net> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com><464DE027.5000000@internap.com> <0e6501c7998e$53068350$f91389f0$@net> Message-ID: > To a first order I agree with Randy that it is not the RIR's > job to force the members to be proactive. At the same time it > is a reasonable part of stewardship to make sure the > membership is informed so the inevitable claims about 'you > didn't tell me' can be dealt with. In light of this, the > message has to go out to everyone, not just those that are > actively applying; so the past policy proposals appear to be > short-sighted in that you only find out about the change when > you come knocking for more. This is an area where ARIN, and the RIRs in general, are failing badly. Why does ARIN not issue press releases to the technology press on a regular basis with statistical highlights? The discussion we are having right now is the equivalent of "backroom politics". It is not open and frank. It involves a tiny in-group who track this stuff all the time. I suspect that in most ARIN member companies, the activities of ARIN are unknown to anyone expect the ARIN contacts and a few technical people. This is the kind of information that needs to be on the desks of decision-makers because without the information, they cannot make decisions on the matter. --Michael Dillon From iljitsch at muada.com Sun May 20 17:47:29 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 20 May 2007 23:47:29 +0200 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com><464DE027.5000000@internap.com> <0e6501c7998e$53068350$f91389f0$@net> Message-ID: <36DC2947-C489-4B2F-B753-EEF180080798@muada.com> On 20-mei-2007, at 23:02, wrote: > Why does ARIN not issue press releases to the technology press on a > regular basis with statistical highlights? They publish statistics on their FTP server every DAY. People like me then download these and create stuff like this: http://www.bgpexpert.com/addrspace2006.php Let me know if there is anything you feel could be added or clarified, or if publishing this more than once a year would be useful. > This is the kind of information that needs to be on the desks of > decision-makers because without the information, they cannot make > decisions on the matter. I should hope that people who don't know how to find this information aren't in a position to make decisions about it. From BillD at cait.wustl.edu Sun May 20 18:19:55 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Sun, 20 May 2007 17:19:55 -0500 Subject: [ppml] Policy Proposal: IPv4 Soft Landing References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com><464DE027.5000000@internap.com><0e6501c7998e$53068350$f91389f0$@net> Message-ID: I agree that this is a matter of information distribution and awareness. I interact with many large end site companies on a regular basis and by and large this issue is not on their radar screens. June 7th we do have a member event where senior technologist will hear an IPv6 presentation. I am very interested to see the turnout for the event and also the reaction and interaction the topic generates. Bill Darte CAIT Washington University in St. Louis -----Original Message----- From: ppml-bounces at arin.net on behalf of michael.dillon at bt.com Sent: Sun 5/20/2007 4:02 PM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing > To a first order I agree with Randy that it is not the RIR's > job to force the members to be proactive. At the same time it > is a reasonable part of stewardship to make sure the > membership is informed so the inevitable claims about 'you > didn't tell me' can be dealt with. In light of this, the > message has to go out to everyone, not just those that are > actively applying; so the past policy proposals appear to be > short-sighted in that you only find out about the change when > you come knocking for more. This is an area where ARIN, and the RIRs in general, are failing badly. Why does ARIN not issue press releases to the technology press on a regular basis with statistical highlights? The discussion we are having right now is the equivalent of "backroom politics". It is not open and frank. It involves a tiny in-group who track this stuff all the time. I suspect that in most ARIN member companies, the activities of ARIN are unknown to anyone expect the ARIN contacts and a few technical people. This is the kind of information that needs to be on the desks of decision-makers because without the information, they cannot make decisions on the matter. --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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kavalec at BSWA.com Sun May 20 19:34:54 2007 From: Kavalec at BSWA.com (G. Waleed Kavalec) Date: Sun, 20 May 2007 17:34:54 -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 Iljitsch van Beijnum Sent: Sunday, May 20, 2007 3:47 PM To: Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing On 20-mei-2007, at 23:02, wrote: > Why does ARIN not issue press releases to the technology press on a > regular basis with statistical highlights? They publish statistics on their FTP server every DAY. People like me then download these and create stuff like this: http://www.bgpexpert.com/addrspace2006.php Let me know if there is anything you feel could be added or clarified, or if publishing this more than once a year would be useful. ------------------------------------------ I think Mike already did. ISSUE PRESS RELEASES We need some kind of "Internet facing its own Y2K" story line - and it needs to be kept alive, even if "y2k" is a bit of hyperbole. From jeroen at unfix.org Sun May 20 18:59:56 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 20 May 2007 23:59:56 +0100 Subject: [ppml] getting converts to V6 In-Reply-To: <4650B317.7090607@Dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> Message-ID: <4650D2EC.5000002@spaghetti.zurich.ibm.com> Lee Dilkie wrote: [..] > "You" refers to producers of IP address space, in this case ARIN and > ARIN's members, the ISPs. I'm not included in that list as I am not an > ARIN member and as I've been made painfully aware, not entitled to > making policy decisions. That is nonsense, as anybody who wants, can participate in the policy making process of (afaik) all the RIR's. You don't have to be an ISP to participate, you just need to provide (technically) valid arguments. For one, I am not an ISP, nor do I work for one, still I can raise my voice on this list and propose things that in my opinion would be good for ARIN to do. Of course a lot of people don't like my ideas and what I say, and they come up with their argumentation about it, therefor defeating my statements, which I then have to adjust to counter them. That is called discussion and negotiation. > "They" refers to the consumers of IP address space, the end customers > for the most part. It's those folks who need to be convinced to make the > move to IPv6. Why do they need to be convinced? It is the ISP that needs to provide the service to the enduser, as such the end user should ask for this service from their ISP. Then their ISP can provide it to the enduser. When you as an enduser run your own (Internet connected) network then you are in effect ISP. The enduser pays the ISP, as such vote with your money. If you don't like what they are doing, tell them, if they keep on doing that, change ISP, if there is no other ISP and you really think you have a valid point, set up your own ISP. After all, it is a free market (at least they claim it is ;) > If all the dire predictions are true, the producers will be out of a job > unless they can convince the consumers to switch to the new address > space. Why would they be out of a job? A lot of ISP's have enough address space handy to last for quite some time, base reason being that address space is provided with a 2 year forecast in some regions. They can also provide connectivity in other ways. > Not unlike Microsoft's efforts to convince us that a new OS is a > "must have" every few years.... What does M$ have to do with ARIN? Except that they are a long way ahead already and providing several transition mechanisms to IPv6. Same as with the ISP, if you don't like it, vote with your money and do something else. You actually do have the freedom you know. Complaining about it to a mass of people who do not work there, or actually can't care less about your whining, won't help you any step further to accomplish where you are whining about. If you have something against the RIR process, then _propose_ an alternate path. Methods of proposing are on the website and accessible to everybody, ARIN member or not. It's like a real democracy, but then not the US kind and actually open. Here your voice, when properly put, is actually listened to. Also, as mentioned on this list, in this very thread, there are people who can help you formulate those proposals. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From fjm.f73.34 at fastq.com Sun May 20 19:34:06 2007 From: fjm.f73.34 at fastq.com (fjm.f73.34 at fastq.com) Date: Sun, 20 May 2007 16:34:06 -0700 Subject: [ppml] UN SUBSCRIBE !!! Message-ID: <5.1.1.6.2.20070520163223.00b14790@pop.fastq.com> I have asked you to unsubscribe me. I am still getting needless email from your source .... fm From aaron at crucialp.com Sun May 20 20:11:08 2007 From: aaron at crucialp.com (Aaron Weller // Crucial Paradigm) Date: Mon, 21 May 2007 10:11:08 +1000 Subject: [ppml] UN SUBSCRIBE !!! In-Reply-To: <5.1.1.6.2.20070520163223.00b14790@pop.fastq.com> References: <5.1.1.6.2.20070520163223.00b14790@pop.fastq.com> Message-ID: <4650E39C.4080408@crucialp.com> http://lists.arin.net/mailman/listinfo/ppml ^ follow the link at the bottom of each email you receive from this mailing list fjm.f73.34 at fastq.com wrote: > I have asked you to unsubscribe me. I am still getting needless email from > your source .... > fm > > _______________________________________________ > 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 Sun May 20 20:42:20 2007 From: drc at virtualized.org (David Conrad) Date: Sun, 20 May 2007 19:42:20 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <4650B317.7090607@Dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> Message-ID: Lee, On May 20, 2007, at 3:44 PM, Lee Dilkie wrote: > "You" refers to producers of IP address space, in this case ARIN and > ARIN's members, the ISPs. I'm not included in that list as I am not an > ARIN member and as I've been made painfully aware, not entitled to > making policy decisions. As an individual, no, you are not entitled to make policy decisions. You are not Lord God Emperor of the Internet (at least as far as I am aware). You are, however, like everyone else entitled to participate in the policy making process. > If all the dire predictions are true, the producers will be out of > a job > unless they can convince the consumers to switch to the new address > space. Not really. The RIRs business models will change and they may look very differently than what they look like now, but the lack of IPv4 address space does not automatically imply they will be "out of a job". > No offense. But the cost of assigning me a drivers license, including > all the testing and whatnot, is *far* less than ARIN's fees. There may be a few more people obtaining drivers licenses than there are requesting blocks of addresses. > Someone is making a boatload of money here. Or wasting a boatload. ARIN's budget is published at http://www.arin.net/about_us/corp_docs/ budget.html. Please point to where someone is making or wasting a boatload of money. > Either way, my original statement stands. Your original statement remains a demonstration of ignorance. Rgds, -drc From Lee at Dilkie.com Sun May 20 23:15:20 2007 From: Lee at Dilkie.com (Lee Dilkie) Date: Sun, 20 May 2007 23:15:20 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> Message-ID: <46510EC8.9080309@Dilkie.com> David Conrad wrote: > Lee, > > On May 20, 2007, at 3:44 PM, Lee Dilkie wrote: > >> "You" refers to producers of IP address space, in this case ARIN and >> ARIN's members, the ISPs. I'm not included in that list as I am not an >> ARIN member and as I've been made painfully aware, not entitled to >> making policy decisions. >> > > As an individual, no, you are not entitled to make policy decisions. > You are not Lord God Emperor of the Internet (at least as far as I am > aware). You are, however, like everyone else entitled to participate > in the policy making process. > Never said I was, never tried to make policy decisions. Where did I give that impression? I'm happy to hear that I do have the right to participate in the process, that was something I didn't know. > >> If all the dire predictions are true, the producers will be out of >> a job >> unless they can convince the consumers to switch to the new address >> space. >> > > Not really. The RIRs business models will change and they may look > very differently than what they look like now, but the lack of IPv4 > address space does not automatically imply they will be "out of a job". > Fair enough. When I said "out of a job" I meant "with no more addresses to give out, they will be out looking for other ways to continue, as it's rare that anyone simply closes up shop when the situation changes". My lack of clear and concise wording is obviously my undoing. > >> No offense. But the cost of assigning me a drivers license, including >> all the testing and whatnot, is *far* less than ARIN's fees. >> > > There may be a few more people obtaining drivers licenses than there > are requesting blocks of addresses. > And that makes it inefficient? Now that's a pretty interesting argument. > >> Someone is making a boatload of money here. Or wasting a boatload. >> > > ARIN's budget is published at http://www.arin.net/about_us/corp_docs/ > budget.html. Please point to where someone is making or wasting a > boatload of money. > URL given results in: Forbidden You don't have permission to access /about_us/corp_docs/ on this server. > >> Either way, my original statement stands. >> > > Your original statement remains a demonstration of ignorance. > Thanks for pointing that out, David. I feel so very welcome when I post to this list and folks like you are so polite with my mistakes. > 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 james at towardex.com Sun May 20 23:43:29 2007 From: james at towardex.com (James Jun) Date: Sun, 20 May 2007 23:43:29 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <46510EC8.9080309@Dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <46510EC8.9080309@Dilkie.com> Message-ID: <000f01c79b5a$4139fdf0$1efc5dd8@HCMC.local> > URL given results in: > > > Forbidden > > You don't have permission to access /about_us/corp_docs/ on this server. > > > >> Either way, my original statement stands. > >> Word wrap... forgot the "budget.html" at the end of your URL. According to: http://www.arin.net/about_us/corp_docs/budget.html : Total 2007 Revenues: $10,441,050 Total 2007 Expenses: $10,311,978 You can see that most of funds are being depleted for services provided thus non-profit charter. Also, you can participate more actively in ARIN policy process if you are a paying member (i.e. IPv4 subscriber), including attending to ARIN meetings. In addition, 6 of ARIN's seven Board of Trustees are also elected by the paying membership. Lastly, much of ARIN's prices/fee schedule are also reflected upon and voted by its membership when such policy proposals to alter pricing exist. It's not that anyone in private is wrecking up $$$ while others pay thru the nose; but instead, everyone is welcomed to participate in making policy decisions. Hope this helps, james From bmanning at karoshi.com Sun May 20 23:38:39 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Mon, 21 May 2007 03:38:39 +0000 Subject: [ppml] getting converts to V6 In-Reply-To: <46510EC8.9080309@Dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <46510EC8.9080309@Dilkie.com> Message-ID: <20070521033839.GA14295@vacation.karoshi.com.> > > > > ARIN's budget is published at http://www.arin.net/about_us/corp_docs/ > > budget.html. Please point to where someone is making or wasting a > > boatload of money. > > > URL given results in: > > > Forbidden > > You don't have permission to access /about_us/corp_docs/ on this server. just as a point of confirmation, I too get the same message when attempting access to http://www.arin.net/about_us/corp_docs/ however, when i try and load the link David originally posted: http://www.arin.net/about_us/corp_docs/budget.html seems to load just fine for me. Please give it a shot. wrt other considerations, i'd be happy to chat off list. --bill From Lee at Dilkie.com Sun May 20 23:48:18 2007 From: Lee at Dilkie.com (Lee Dilkie) Date: Sun, 20 May 2007 23:48:18 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <4650D2EC.5000002@spaghetti.zurich.ibm.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <4650D2EC.5000002@spaghetti.zurich.ibm.com> Message-ID: <46511682.3050902@Dilkie.com> Jeroen Massar wrote: > Lee Dilkie wrote: > ... skipped part about policy... >> "They" refers to the consumers of IP address space, the end customers >> for the most part. It's those folks who need to be convinced to make the >> move to IPv6. >> > > Why do they need to be convinced? It is the ISP that needs to provide > the service to the enduser, as such the end user should ask for this > service from their ISP. Then their ISP can provide it to the enduser. > huh? See my post about pushing a rope. The ISP cannot simply force end users to take IPv6, there are hardly any working applications that work on that network at present. It's not about "providing the service", you need to create demand first. (Can you imagine starting up a TV broadcast station before the TV itself was invented?) > When you as an enduser run your own (Internet connected) network then > you are in effect ISP. > > The enduser pays the ISP, as such vote with your money. If you don't > like what they are doing, tell them, if they keep on doing that, change > ISP, if there is no other ISP and you really think you have a valid > point, set up your own ISP. After all, it is a free market (at least > they claim it is ;) > And you live on what planet? Even in countries that do not have government control over telecommunications, the entry costs make this an impractical solution. >> Not unlike Microsoft's efforts to convince us that a new OS is a >> "must have" every few years.... >> > > What does M$ have to do with ARIN? Except that they are a long way ahead > already and providing several transition mechanisms to IPv6. > That was an example of an industry (and a single player in that industry) that does understand that demand must be created. Other industries, like automotive, music, film, home furnishings and the fashion industry all understand this thing about "creating demand". Pet rocks and the chia pet are good examples of folks that had initial success and failed to create a follow-on demand. And all this fits how, you ask? The original email talked of trying to get folks converted to IPv6. I pointed out that, contrary to some other opinions, it's not the ISPs that need converting (though they certainly do, but they will anyway to follow the money) but rather the industry (the "internet") needs to create demand to move to IPv6 with some as-yet-discovered killer IPv6 application that will make the switch a compelling one for the end users. Sometimes the killer app is real, sometimes it's a marketing exercise (as Microsoft and others are sometimes guilty of). Either way, the solution to moving folks is the same, create demand. And for that, you need early adopters to dive in, get religious and do their thing. But that argument already received it's share of "you must show *need*" cries from those that don't see things the way I do. Oh well. BTW. When I see folks refer to Microsoft as M$, I generally assume that they are trolling. Either that or they have such an irrational hatred that it affects their judgment. Either way, I tend not to respond as it's seldom productive. Of course that would be on lower brow lists than this one. We're all professionals here. -lee From drc at virtualized.org Mon May 21 00:38:28 2007 From: drc at virtualized.org (David Conrad) Date: Sun, 20 May 2007 23:38:28 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <46510EC8.9080309@Dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <46510EC8.9080309@Dilkie.com> Message-ID: <75F21F4F-F730-4A33-98C0-E23C50B2BBD6@virtualized.org> Lee, On May 20, 2007, at 10:15 PM, Lee Dilkie wrote: >>> No offense. But the cost of assigning me a drivers license, >>> including >>> all the testing and whatnot, is *far* less than ARIN's fees. >> There may be a few more people obtaining drivers licenses than there >> are requesting blocks of addresses. > And that makes it inefficient? Now that's a pretty interesting > argument. It isn't about efficiency or lack thereof. Obviously, the fees you pay for a driver's license is significantly smaller than the fees you would pay for an address allocation. Part of the reason for this is that since ARIN (like the other RIRs) works on a cost recovery basis, the fewer number of fee payers, the larger the fee per payer. While DMVs operate on a different model, the use fees associated with driver licenses reflect a much, much larger payer base and hence are much smaller than the fees folks would pay if the total payer base was on the order of 1000. > You don't have permission to access /about_us/corp_docs/ on this > server. Apologies. As others have pointed out, the URL wrapped. The correct URL is: >> Your original statement remains a demonstration of ignorance. > Thanks for pointing that out, David. I feel so very welcome when I > post > to this list and folks like you are so polite with my mistakes. "Ig-no-rance: noun, lack of knowledge or information." -- Oxford American Dictionary My comment wasn't intended as an insult. Honestly. I personally freely admit I am ignorant about most things. Ignorance only becomes a problem when people don't try to remedy it during discussions. Rgds, -drc From iljitsch at muada.com Mon May 21 04:27:09 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 21 May 2007 10:27:09 +0200 Subject: [ppml] getting converts to V6 In-Reply-To: <46511682.3050902@Dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <4650D2EC.5000002@spaghetti.zurich.ibm.com> <46511682.3050902@Dilkie.com> Message-ID: <0873EAD5-E47A-4D79-9BC5-9B2298F58F36@muada.com> On 21-mei-2007, at 5:48, Lee Dilkie wrote: > The ISP cannot simply force end > users to take IPv6, there are hardly any working applications that > work > on that network at present. That's not true. Some examples of applications that work with IPv6: - Internet Explorer - Windows Media Player - Firefox - Thunderbird - Quicktime Player - iTunes - Safari - Apple's Mail - iChat (limited) > It's not about "providing the service", you > need to create demand first. (Can you imagine starting up a TV > broadcast > station before the TV itself was invented?) It's more like the addition of color, technically speaking. For that to work, viewers must have color TVs, stations must broadcast a color signal and content must be produced in color. You need all three, just one or two won't give you any benefits. Now of course the difference is that color is highly visible to the user, while IPv6 isn't. How can users be expected to go ask for something that they don't even know exists? Waiting for user demand is pointless here. > And all this fits how, you ask? The original email talked of trying to > get folks converted to IPv6. I pointed out that, contrary to some > other > opinions, it's not the ISPs that need converting (though they > certainly > do, but they will anyway to follow the money) but rather the industry > (the "internet") needs to create demand to move to IPv6 with some > as-yet-discovered killer IPv6 application that will make the switch a > compelling one for the end users. Ah, the mythical killer app. There are basically two types of applications, and IPv6 can't be a requirement for either of those: - client/server apps: these work without problems today, nothing IPv6 could add - peer-to-peer apps: don't work so well today, but requiring IPv6 means the app is dead in the water Or in other words: in today's world, it's always more beneficial to get something working over IPv4, even though that may be hard and unreliable, rather than to get the entire user population to adopt IPv6. To get IPv6 adopted you need to have IPv6 capability in the following places: 1. user side application 2. user OS 3. SOHO gateway/CPE 4. ISP networks 5. content side firewalls and load balancers 6. content side OS 7. server application By now, 2 and 6 are not a problem. 1 and 7 aren't always there yet, but there is enough software that supports IPv6 to make a good start. 4 is largely doable, although there is probably still some equipment out there that can't do IPv6 at all or not at the same speeds as IPv4. But the real problems are 3 and 5. I have native IPv6 connectivity over ADSL. However, this required me to pay several times more for my ADSL modem in the form of a Cisco 826/827 and it required manual configuration on both ends of the ADSL link. With IPv4, you can pretty much buy any ADSL or cable modem, plug it in and it works. Not so with IPv6, because there is no standard way for ISPs to provision the CPE boxes with an IPv6 address range. This is very similar to the situation we had when ISDN first came available in the mid-1990s: everyone used different protocols so it was very hard to get it working. But after a while a standard way to do it came about and ISDN became easier to deploy than analog modems. I don't have a very good view of what's going on on the content side, but as far as I know, the fancy stuff used to serve up content to huge audiences can't do IPv6 on the same level as IPv4 right now. So what we need to do: Software makers: make your software IPv6-compatible. Content people: push your vendors. Cable and DSL ISPs: talk to the CPE vendors and work out a standard provisioning model. (Hint: DHCPv6 prefix delegation can work wonders here.) ISPs in general: for now, set up a tunnel broker for your customers. That gives those who care enough to manually configure it most of the benefits of IPv6 but it's only a fraction of the hassle. Also set up a private 6to4 relay to provide a better experience for customers who use automatic 6to4 tunneling. "Ask not what IPv6 can do for you; ask what you can do for IPv6." From michael.dillon at bt.com Mon May 21 06:49:10 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 21 May 2007 11:49:10 +0100 Subject: [ppml] UN SUBSCRIBE !!! In-Reply-To: <5.1.1.6.2.20070520163223.00b14790@pop.fastq.com> References: <5.1.1.6.2.20070520163223.00b14790@pop.fastq.com> Message-ID: > I have asked you to unsubscribe me. I am still getting > needless email from your source .... If you did not succeed with the information in the URL at the bottom of this message then you need to contact the ARIN president Ray Plzak [plzak at arin.net] and ask him to get this fixed. There is a known problem with the URL below and Ray is the only person who can get it fixed at this point. > > _______________________________________________ > 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 craig.finseth at state.mn.us Mon May 21 08:48:40 2007 From: craig.finseth at state.mn.us (Craig Finseth) Date: Mon, 21 May 2007 07:48:40 -0500 Subject: [ppml] getting converts to V6 References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <4650D2EC.5000002@spaghetti.zurich.ibm.com> <46511682.3050902@Dilkie.com> Message-ID: <200705211248.l4LCmeIf016998@inana.itg.state.mn.us> I have some current real-world data to add to the mix. I am with the State of Minnesota. We run the usual sort of large data/voice/video network that is quite common and act as both an ISP and an internal provider. We have some IPv6 deployed on the network. The Cisco routers and Sun workstations run it just fine. I expect that the Windows, Linux and OS X boxes would also work just fine. If any customer asks for it (none have), we can support their IPv6 network across our MPLS backbone. We have a large class of semi-intelligent network devices out there (things like transceivers, UPSs, etc, with IP connectivity). None of those support IPv6, although we have them all in RFC 1918 address space (and always will, even after IPv6 as we don't want them reachable from the Internet), so that isn't a problem. We also just issued an RFP for network management tools. Only one of the responses supports IPv6 ("coming soon" on the rest), and even that one doesn't support it across their entire product line. So, if we had to support IPv6 tomorrow, we couldn't: the products that we need to run the network don't exist yet. We (as a network) really can't start a big move until all of the pieces are in place. Craig A. Finseth craig.finseth at state.mn.us Systems Architect +1 651 201 1011 desk State of Minnesota, Office of Enterprise Technology 658 Cedar Ave +1 651 297 5368 fax St Paul MN 55155 +1 651 297 1111 NOC, for reporting problems From info at arin.net Mon May 21 09:06:05 2007 From: info at arin.net (Member Services) Date: Mon, 21 May 2007 09:06:05 -0400 Subject: [ppml] ARIN Board Advises Internet Community on Migration to IPv6 Message-ID: <4651993D.1020408@arin.net> ARIN and the other Regional Internet Registries have distributed Internet Protocol version 6, IPv6, alongside IPv4 since 1999. To date, ARIN has issued both protocol versions in tandem and has not advocated one over the other. ARIN has closely monitored trends in demand and distribution for both protocol versions with the understanding that the IPv4 available resource pool would continue to diminish. The available IPv4 resource pool has now been reduced to the point that ARIN is compelled to advise the Internet community that migration to IPv6 is necessary for any applications that require ongoing availability from ARIN of contiguous IP number resources. On 7 May 2007, the ARIN Board of Trustees passed the following resolution: RESOLUTION OF THE BOARD OF TRUSTEES OF ARIN ON INTERNET PROTOCOL NUMBERING RESOURCE AVAILABILITY WHEREAS, community access to Internet Protocol (IP) numbering Resources has proved essential to the successful growth of the Internet; and, WHEREAS, ongoing community access to Internet Protocol version 4 (IPv4) numbering resources can not be assured indefinitely; and, WHEREAS, Internet Protocol version 6 (IPv6) numbering resources are available and suitable for many Internet applications, BE IT RESOLVED, that this Board of Trustees hereby advises the Internet community that migration to IPv6 numbering resources is necessary for any applications which require ongoing availability from ARIN of contiguous IP numbering resources; and, BE IT ORDERED, that this Board of Trustees hereby directs ARIN staff to take any and all measures necessary to assure veracity of applications to ARIN for IPv4 numbering resources; and, BE IT RESOLVED, that this Board of Trustees hereby requests the ARIN Advisory Council to consider Internet Numbering Resource Policy changes advisable to encourage migration to IPv6 numbering resources where possible. Implementation of this resolution will include both internal and external components. Internally, ARIN will review its resource request procedures and continue to provide policy experience reports to the Advisory Council. Externally, ARIN will send progress announcements to the ARIN community as well as the wider technical audience, government agencies, and media outlets. ARIN will produce new documentation, from basic introductory fact sheets to FAQs on how this resolution will affect users in the region. ARIN will focus on IPv6 in many of its general outreach activities, such as speaking engagements, trade shows, and technical community meetings. For more information visit the IPv6 Information Center at: http://www.arin.net/v6/v6-info.html. Regards, Raymond A. Plzak President and CEO American Registry for Internet Numbers (ARIN) From randy at psg.com Mon May 21 09:06:11 2007 From: randy at psg.com (Randy Bush) Date: Mon, 21 May 2007 09:06:11 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: <0873EAD5-E47A-4D79-9BC5-9B2298F58F36@muada.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <4650D2EC.5000002@spaghetti.zurich.ibm.com> <46511682.3050902@Dilkie.com> <0873EAD5-E47A-4D79-9BC5-9B2298F58F36@muada.com> Message-ID: <46519943.1090903@psg.com> >> The ISP cannot simply force end users to take IPv6, there are hardly >> any working applications that work on that network at present. > That's not true. Some examples of applications that work with IPv6: the problem is more the ones which do not. if a server is v6 enabled, then ALL SERVICES must be v6 capable or there are painful failures. randy From iljitsch at muada.com Mon May 21 09:33:20 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 21 May 2007 15:33:20 +0200 Subject: [ppml] getting converts to V6 In-Reply-To: <46519943.1090903@psg.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <4650D2EC.5000002@spaghetti.zurich.ibm.com> <46511682.3050902@Dilkie.com> <0873EAD5-E47A-4D79-9BC5-9B2298F58F36@muada.com> <46519943.1090903@psg.com> Message-ID: On 21-mei-2007, at 15:06, Randy Bush wrote: >>> The ISP cannot simply force end users to take IPv6, there are hardly >>> any working applications that work on that network at present. >> That's not true. Some examples of applications that work with IPv6: > the problem is more the ones which do not. > if a server is v6 enabled, then ALL SERVICES must be v6 capable or > there are > painful failures. If a DNS name has an IPv6 address associated with it, then clients are going to try using IPv6 towards the server with that name. If a service then doesn't support IPv6 the clients will encounter an error message, which in most cases means they immediately try again over IPv4. But using different DNS names for different services, even if they're hosted on the same physical or logical server, makes it easy to selectively add IPv6 capability to different services. (This also makes it easier to move the service to another server so it's a good idea to do this anyway.) From randy at psg.com Mon May 21 09:49:27 2007 From: randy at psg.com (Randy Bush) Date: Mon, 21 May 2007 09:49:27 -0400 Subject: [ppml] getting converts to V6 In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <4650D2EC.5000002@spaghetti.zurich.ibm.com> <46511682.3050902@Dilkie.com> <0873EAD5-E47A-4D79-9BC5-9B2298F58F36@muada.com> <46519943.1090903@psg.com> Message-ID: <4651A367.7080204@psg.com> >> if a server is v6 enabled, then ALL SERVICES must be v6 capable or >> there are painful failures. > If a DNS name has an IPv6 address associated with it, then clients are > going to try using IPv6 towards the server with that name. If a service > then doesn't support IPv6 the clients will encounter an error message, > which in most cases means they immediately try again over IPv4. nice theory. in practice, if all services do not support v6, then you will be getting noc calls. randy From Ed.Lewis at neustar.biz Mon May 21 10:04:39 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 21 May 2007 10:04:39 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <1DF543FC-F0EC-4832-894F-DC8EDC5B7822@virtualized.org> References: <464425E7.1070305@arin.net> <1DF543FC-F0EC-4832-894F-DC8EDC5B7822@virtualized.org> Message-ID: At 9:30 -0500 5/17/07, David Conrad wrote: (I wrote) >> I assume that this isn't retroactive. > >I'm not sure what this means. Someone asked if the proposal was "retroactive"...lemme see if I can find the message in the archives... ah, here 'tis... http://lists.arin.net/pipermail/ppml/2007-May/006909.html "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." So - my comment was that I would "vote/opine" "no" to the question of whether this policy would make ARIN go back through records and revoke folks no longer meeting the changing criteria. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From BillD at cait.wustl.edu Mon May 21 10:20:43 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 21 May 2007 09:20:43 -0500 Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 Message-ID: Congratulations to the Board for their historic pronouncement related to IPv4 and IPv6 address management. I hope that this announcement was forwarded to the media as well as ARIN-announce. And, I hope that each of you consider forwarding their announcement to your customers and community media. Bill Darte ARIN Advisory Council -------------- next part -------------- An HTML attachment was scrubbed... URL: From plzak at arin.net Mon May 21 10:27:35 2007 From: plzak at arin.net (Ray Plzak) Date: Mon, 21 May 2007 10:27:35 -0400 Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 In-Reply-To: References: Message-ID: Bill, We have sent a press release to the media and are actively engaged in other media related activities around this subject. Thanks for encouraging others to help spread the word. Ray From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Bill Darte Sent: Monday, May 21, 2007 10:21 AM To: ppml at arin.net Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 Congratulations to the Board for their historic pronouncement related to IPv4 and IPv6 address management. I hope that this announcement was forwarded to the media as well as ARIN-announce. And, I hope that each of you consider forwarding their announcement to your customers and community media. Bill Darte ARIN Advisory Council -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at FiberInternetCenter.com Mon May 21 11:02:01 2007 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 21 May 2007 08:02:01 -0700 (PDT) Subject: [ppml] [PPLM] ARIN Board Advises Internet Community on Migration to IPv6 Message-ID: <64795.76.204.76.13.1179759721.squirrel@bobevans.net> I wonder how "effective" this suggestion from our board will be? Considering the desire for transition by our organization, lack of a fee wavier date NOT changing isnt that great. As in about 7 months the new fees are implemented. >From the ARIN fee page: "A partial fee waiver is in effect. All fees referenced below will apply only after the expiration of the waiver on 31 December 2007. Until then the fee for all IPv6 assignments is $500." I thinks it is great the board advises IPv6 migration and statistic information is well presented for the "sale decision". However, it is clear that ARIN will collect fees from both IPv6 and IPv4 assignments for a period of years. I think it feels a bit like, a bait and switch fee doubling tactic on the fees side, NOT to consider the fee wavier expiration date. If one wants or needs a future conversion to be effective, there should at least appear to be an positive incentive. This one is clearly negative, as it promises that one's fees will in fact double at the end of this year. A small/medium size ISP the fees effectively double after December 2007, while their transit for IPv6 could remain unresolved and other conversion issues require considerable labor and hardware costs. With this in consideration and a fee doubling on the near horizon, you can see how a smaller/medium ISP will continue to procrastinate. I hope someone will kept track of the request statistics 30 days after this advisory was sent. It will help us evaluate or community's ability to listen to board advise vs. the willingness to incur a 100% cost increase. bob evans From Crumb_Anthony_A at cat.com Mon May 21 11:37:27 2007 From: Crumb_Anthony_A at cat.com (Anthony A. Crumb) Date: Mon, 21 May 2007 10:37:27 -0500 Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 In-Reply-To: Message-ID: I think it is great that we are spreading the word, and I am glad that ARIN has made this announcement. Now we need to put the issue ULA-central or ULA-local to bed. I am sure that I will not be able to justify more than one /48 globally routable prefix for my US internet presence. Because the last 64 bits of the address are required for interface identifiers that only leaves me with 16 bits with which to create a hierarchical enterprise address allocation model. 16 bit of subnetting space is not enough to create subnet allocation model for a large enterprise. It would seem to me that I would want to use the globally routable /48 for internet facing environments and some form of ULA space internally. We try very hard to employ only RFC based solution in our environments. When are we going to see an end to the debate over ULA-Central and ULA-Local? I have been working with RFC4193 "random" method to create address space for my internal networks but I do not want to move forward with deployment until there is some "ratified" RFC in place that helps to guild my address allocation strategy. To be blunt I don't have time to go through the effort of building a design just to have to rework it because the space the RFC4193 defines and ULA-Local gets broken up and allocated to RIRs, LIRs, ISPs, and or carriers to hand out as ULA-Central. I want to adopt v6 and get started but I can't afford false starts and rework. Anyone else of like mind, or opinion? Anthony A. Crumb Ray Plzak Sent by: ppml-bounces at arin.net 05/21/2007 09:27 AM To Bill Darte "ppml at arin.net" cc Subject Re: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 Caterpillar: Confidential Green Retain Until: 06/20/2007 Retention Category: G90 - General Matters/Administration Bill, We have sent a press release to the media and are actively engaged in other media related activities around this subject. Thanks for encouraging others to help spread the word. Ray From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Bill Darte Sent: Monday, May 21, 2007 10:21 AM To: ppml at arin.net Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 Congratulations to the Board for their historic pronouncement related to IPv4 and IPv6 address management. I hope that this announcement was forwarded to the media as well as ARIN-announce. And, I hope that each of you consider forwarding their announcement to your customers and community media. Bill Darte ARIN Advisory Council_______________________________________________ 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 drc at virtualized.org Mon May 21 11:40:51 2007 From: drc at virtualized.org (David Conrad) Date: Mon, 21 May 2007 08:40:51 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net> <1DF543FC-F0EC-4832-894F-DC8EDC5B7822@virtualized.org> Message-ID: <2DBEF5AD-50B4-4D49-9077-56969F378C5A@virtualized.org> Ed, On May 21, 2007, at 7:04 AM, Edward Lewis wrote: >>> I assume that this isn't retroactive. >> I'm not sure what this means. > "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." Ah. No, it wasn't my intention to make "Soft Landing" retroactive. Rgds, -drc From iljitsch at muada.com Mon May 21 11:53:23 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 21 May 2007 17:53:23 +0200 Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 In-Reply-To: References: Message-ID: <9945A833-7B63-4BAD-9215-3B61BB0A1C5E@muada.com> On 21-mei-2007, at 17:37, Anthony A. Crumb wrote: > I have > been working with RFC4193 "random" method to create address space > for my > internal networks but I do not want to move forward with deployment > until > there is some "ratified" RFC in place that helps to guild my address > allocation strategy. To be blunt I don't have time to go through the > effort of building a design just to have to rework it because the > space > the RFC4193 defines and ULA-Local gets broken up and allocated to > RIRs, > LIRs, ISPs, and or carriers to hand out as ULA-Central. I want to > adopt v6 > and get started but I can't afford false starts and rework. Anyone > else of > like mind, or opinion? Yes, it would be good to get ULA-central off the ground. This shouldn't be too hard, should it? Just allow the domain sellers to sell domains under c.f.ip6.arpa: quick, easy, cheap. From drc at virtualized.org Mon May 21 11:59:34 2007 From: drc at virtualized.org (David Conrad) Date: Mon, 21 May 2007 08:59:34 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> Message-ID: <3095BF3B-CDAA-4FD2-AF3C-357B05486B98@virtualized.org> Iljitsch, On May 18, 2007, at 8:15 AM, Iljitsch van Beijnum wrote: > The effect of a policy like this is that: > > a. IPv4 becomes more painful to use because addresses are harder to > get I'm not sure I see how IPv4 addresses would be more painful to use if they are harder to obtain. If you have obtained the addresses, you use them like you always have. > b. the incentive to move to IPv6 is reduced because the moment that > the > IPv4 is completely depleted is postponed If people don't feel the need to migrate to IPv6 in the face of increased restrictions on obtaining IPv4, then presumably they have come up with alternative solutions to IPv4 free pool run out. > c. in many cases, the same amount of address space as before is given > out, but now as many small blocks, increasing the ARIN workload and > hindering route aggregation Sorry, don't follow this one. >> Phase 1 >> Threshold 40 /8s > > This will almost certainly happen within a year, with about 25% of > the IPv4 address space or around a billion addresses still unused. Probably. > Don't forget that in addition to what's available in the IANA global > pool, there is also a lot of address space still available but held > by the RIRs. Currently, about 24 /8s worth. If so, then it would be less likely the RIRs would need to obtain address space from IANA, no? Rgds, -drc From owen at delong.com Mon May 21 12:00:46 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 21 May 2007 09:00:46 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <4650B317.7090607@Dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> Message-ID: > > "You" refers to producers of IP address space, in this case ARIN and > ARIN's members, the ISPs. I'm not included in that list as I am not an > ARIN member and as I've been made painfully aware, not entitled to > making policy decisions. If I were an ARIN member, I would have > used the > term "we". > This makes little sense. First, ARIN and the other RIRs do not produce IP address space, they register its usage in an effort to preserve some level of assurance of uniqueness. Second, anyone is entitled to a role in the policy decision process. You do not have to be an ARIN member in order to do so. In fact, many of ARIN's members are NOT ISPs. Further, I have written policy proposals at times when I was not an ARIN member and not participating as part of my work for any ARIN member. The policy process is very clearly open to anyone who has an interest in participating. > "They" refers to the consumers of IP address space, the end customers > for the most part. It's those folks who need to be convinced to > make the > move to IPv6. > For the most part, the end-users do not care what protocol they use. All they care about is being able to click a link and get the content they want. As such, the first step will have to be convincing the content providers to provide interesting content on IPv6. When the majority of existing content is available on IPv6, then, new content that is not available on IPv4 might actually produce a migration at the end-user level. > If all the dire predictions are true, the producers will be out of > a job > unless they can convince the consumers to switch to the new address > space. Not unlike Microsoft's efforts to convince us that a new OS > is a > "must have" every few years.... As others have said (and my mechanical > engineering prof first told me), you can't push a rope. You need to > make > it a compelling decision. Going about this like a typical government > organization is not the way to reach your goals. Throwing up > artificial > costs is hardly a good start... This simply isn't true. First, the registration of existing space will still be a necessary function, even if there isn't free space. ARIN gets paid annually by the existing holders of address space. Unlike Micr0$0ft who doesn't get paid unless people upgrade, ARIN gets paid regardless. >> Cost of assigning a number includes the time to evaluate the >> request, time to record it, and maintenance of the recording >> system, not to mention infrastructure around it. >> > No offense. But the cost of assigning me a drivers license, including > all the testing and whatnot, is *far* less than ARIN's fees. > Someone is > making a boatload of money here. Or wasting a boatload. Either way, my > original statement stands. > Actually, the cost of assigning you a drivers license far exceed what you pay for it at DMV. It's subsidized through gasoline taxes, and, if you were to pay the true cost of maintaining a drivers license it would far exceed the annual fees charged by ARIN to end users. Comparing a non-profit corporations operation to that of a subsidized government entity that happens to charge a fee that does not completely cover the cost of the operation in question is hardly an accurate or meaningful comparison. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From kloch at kl.net Mon May 21 12:10:01 2007 From: kloch at kl.net (Kevin Loch) Date: Mon, 21 May 2007 12:10:01 -0400 Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 In-Reply-To: References: Message-ID: <4651C459.60201@kl.net> Anthony A. Crumb wrote: > > I think it is great that we are spreading the word, and I am glad that > ARIN has made this announcement. Now we need to put the issue > ULA-central or ULA-local to bed. I am sure that I will not be able to > justify more than one /48 globally routable prefix for my US internet > presence. Because the last 64 bits of the address are required for > interface identifiers that only leaves me with 16 bits with which to > create a hierarchical enterprise address allocation model. 16 bit of > subnetting space is not enough to create subnet allocation model for a > large enterprise. The current PI policy does allow for variable sized assignments based upon need for more than 65536 subnets. There have been two such assignments made so far. I'm sure if you submit an application that reasonably justifies your request you can get the subnets you need, as that was the intent of the policy. We do need to make that policy more specific as to what "justify" means so if you have any suggestions we would love to hear them. - Kevin From drc at virtualized.org Mon May 21 12:39:29 2007 From: drc at virtualized.org (David Conrad) Date: Mon, 21 May 2007 09:39:29 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing In-Reply-To: References: <464425E7.1070305@arin.net><30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> Message-ID: <1C688E69-35EF-46C6-A627-12CD0C232D14@virtualized.org> Michael, On May 18, 2007, at 9:48 AM, wrote: > I would prefer to see a new policy that says effective immediately, > all > applications for assignments or allocations must include the > answers to > a set of questions about the organization's preparations for IPv6. Sounds like a reasonable policy proposal to make, independent of the "Soft Landing" proposal. Rgds, -drc From drc at virtualized.org Mon May 21 13:00:03 2007 From: drc at virtualized.org (David Conrad) Date: Mon, 21 May 2007 10:00:03 -0700 Subject: [ppml] Soft and hard landings, was: Re: Policy Proposal: IPv4 Soft Landing In-Reply-To: <6A10E8C8-D5E6-4948-A045-EC4FFF3B53EB@muada.com> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> <464DE027.5000000@internap.com> <6A10E8C8-D5E6-4948-A045-EC4FFF3B53EB@muada.com> Message-ID: <45BE03F0-DB82-4B23-B95C-089ADCC61FC9@virtualized.org> Iljitsch, On May 18, 2007, at 2:34 PM, Iljitsch van Beijnum wrote: > You only look at the cost part without considering the benefit. Apart > from less tangible things like being a technology leader or being > prepared, the benefit of adopting IPv6 is negligible: you can only > reach a tiny part of the internet over IPv6: something in the order > of 0.1%. So the cost difference between IPv4 and IPv6 can never drive > IPv6 adoption. Right. As stated in the rationale section, one of the things the "Soft Landing" proposal tries to do is encourage ISPs to break the chicken-and-egg cycle by making IPv6 services and connectivity a pre- requisite for obtaining additional IPv4 space. Since the RIRs have no real way of directly influencing end users, this is the pragmatic approach. [tortured analogies deleted] > We're currently still in the situation where people can fool > themselves into thinking that we're not going to run out of IPv4 > space within the next decade or so, hence they don't have to take any > action. Implementing any measures that postpone the moment of running > out only give people more excuses to ignore IPv6. Perhaps I'm overly optimistic, but I don't think any of the folks who would be affected by "Soft Landing" have any illusions about running out of IPv4 space. What "Soft Landing" tries to do is: - provide a lengthened runway via increased efficiency - give addressing folks within ISPs ammunition to explain to their business folks why taking IPv6 seriously is a good idea My impression is that the business folks at ISPs focus on either what brings in new revenues or what drives down costs. Since IPv6 doesn't appear to be able to bring in new revenues, the only other option I can think of to get their attention is to cause costs to increase. Since costs for obtaining IPv4 are going to increase when the free pool runs out regardless of what the RIRs do, it seems the easiest way to get the business folks' attention so that there can be some preparation is to raise the cost of obtaining IPv4 before the crisis hits. Rgds, -drc From dean at av8.com Mon May 21 13:03:26 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 21 May 2007 13:03:26 -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' > > > > 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. Ok. Then we are agreed that "say" is equal. I think perhaps I misunderstood your message; so long as you aren't disputing that IANA and the DoC has influence over RIRs, we are in agreement. I think we are also in agreement that the RIRs and ICANN/IANA can bypass the IETF by agreeing to do so. The IETF doesn't have any authority to stop IANA from making decisions which contradict the IETF advice to IANA. The IETF doesn't appoint IANA. > > > 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? A fallacy is the false implication of statements supporting a conclusion. One doesn't need false statements to have a fallacy---only a conclusion not supported by the statements. I thought you were asserting that there isn't any control by DoC over RIRs, and that those statements were your justification. That would be a fallacy, but it seems in retrospect you weren't disputing control of DoC over RIRs, so I guess I just misunderstood you. My apologies. However, a nit while I'm at it: The MoU is just a written understanding, and can be terminated at any time by either party. The ICANN bylaws do not need to mention the RIRs for ICANN to contract the IANA function. The absence of RIRs in ICANN bylaws is irrelevant. > > 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. Sorry, this subject sounds to me like CORE, the MoUvement & January 1998 all over again. I may be overreacting to past history. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From bob at FiberInternetCenter.com Mon May 21 13:30:55 2007 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 21 May 2007 10:30:55 -0700 (PDT) Subject: [ppml] Soft and hard landings, was: Re: Policy Proposal: IPv4 Soft Landing In-Reply-To: <45BE03F0-DB82-4B23-B95C-089ADCC61FC9@virtualized.org> References: <464425E7.1070305@arin.net> <30EB1B87-D363-4D58-BB4C-8E6F6A518139@muada.com> <464DE027.5000000@internap.com> <6A10E8C8-D5E6-4948-A045-EC4FFF3B53EB@muada.com> <45BE03F0-DB82-4B23-B95C-089ADCC61FC9@virtualized.org> Message-ID: <50868.71.156.102.142.1179768655.squirrel@bobevans.net> > Perhaps I'm overly optimistic, but I don't think any of the folks who > would be affected by "Soft Landing" have any illusions about running > out of IPv4 space. What "Soft Landing" tries to do is: > > - provide a lengthened runway via increased efficiency > - give addressing folks within ISPs ammunition to explain to their > business folks why taking IPv6 seriously is a good idea > > My impression is that the business folks at ISPs focus on either what > brings in new revenues or what drives down costs. Since IPv6 doesn't > appear to be able to bring in new revenues, the only other option I > can think of to get their attention is to cause costs to increase. While bringing in new revenue isn't around the corner...the fee doubling increase is spelled out on the fees page - while the advice of the board is for everyone to get on board the IPv6 bandwagon...we let them know that there is little incentive as their fees will double in 7 months or so - payment for IPv4 and IPv6 Dec 2007, expire date of IPv6 waiver. So if we think we are helping the IT department to make a case to the business folks - I can tell you that most business's CFOs will see a doubling of fees as a reason wait. To a business guy it's kind of like buying tires , they dont see a need for, because they come with a 90 days of no payments. To me, it seems that our organization is more focused on the negative aspects of marketing the end of the IPv4 world, as opposed to marketing a more incentive oriented approach. A perfect example is the IPv6 request form, riddled with questions that promote postponement and lead to procrastination. We are doing a good job of promoting the end of the world as we know it...but have spent very little effort making sure that everyone knows what the roses smell like in the new world. The request form - the businesses fee doubling effect present a different smell of the roses. Or am I missing something published on ARIN? Could it be I am mistaken (that happens often enough) that our elected are composed of both business savvy and tech savvy individuals? bob evans > Since costs for obtaining IPv4 are going to increase when the free > pool runs out regardless of what the RIRs do, it seems the easiest > way to get the business folks' attention so that there can be some > preparation is to raise the cost of obtaining IPv4 before the crisis > hits. > > 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 > > www.FiberInternetCenter.com From michael.dillon at bt.com Mon May 21 13:41:39 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 21 May 2007 18:41:39 +0100 Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 In-Reply-To: References: Message-ID: > Because the last > 64 bits of the address are required for interface identifiers > that only leaves me with 16 bits with which to create a > hierarchical enterprise address allocation model. 16 bit of > subnetting space is not enough to create subnet allocation > model for a large enterprise. I think this issue needs to be taken up with the IETF. When the /48 subnet model was first created, it was being put forth as a solution for a site, not for an entire enterprise. Since then, some people have applied IPv4 scarcity thinking to IPv6 and decided that a /48 is sufficient for a single organization. As you quite rightly pointed out, this overlooks the interface identifier model of IPv6 and perhaps, recreates a problem which was solved in the IETF years ago. You might want to join the IETF discussion list and bring it up there http://www.ietf.org/maillist.html However I suspect you may get better info by going directly to the IPv6 working group directly. http://www.ietf.org/html.charters/ipv6-charter.html It is best to hurry, because the members of the ipv6 working group are prepared to wrap up their work next month because, from their point of view, the work is done. That may be true since deployment of IPv6 really belongs in v6ops http://www.ietf.org/html.charters/v6ops-charter.html but the whole division of responsibility is a bit fuzzy to me. If you feel the same, go straight to the first list above. >It would seem to me that I > would want to use the globally routable /48 for internet > facing environments and some form of ULA space internally. We > try very hard to employ only RFC based solution in our > environments. When are we going to see an end to the debate > over ULA-Central and ULA-Local? I have been working with > RFC4193 "random" method to create address space for my > internal networks but I do not want to move forward with > deployment until there is some "ratified" RFC in place that > helps to guild my address allocation strategy. To be blunt I > don't have time to go through the effort of building a design > just to have to rework it because the space the RFC4193 > defines and ULA-Local gets broken up and allocated to RIRs, > LIRs, ISPs, and or carriers to hand out as ULA-Central. I > want to adopt v6 and get started but I can't afford false > starts and rework. Anyone else of like mind, or opinion? Given that ULA addressing is defined in RFC 4193 and that this RFC is on the Standards Track, I think it is highly unlikely that the IETF would ever hand that address space over to the RIRs. If you want further assurances on the status of RFC 4193 then it is best to go straight to the IETF and ask them on the IETF discussion mailing list. --Michael Dillon From craig.finseth at state.mn.us Mon May 21 16:51:29 2007 From: craig.finseth at state.mn.us (Craig Finseth) Date: Mon, 21 May 2007 15:51:29 -0500 Subject: [ppml] getting converts to V6 In-Reply-To: <4651F323.9070001@bogus.com> (message from Joel Jaeggli on Mon, 21 May 2007 12:29:39 -0700) References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <4650D2EC.5000002@spaghetti.zurich.ibm.com> <46511682.3050902@Dilkie.com> <200705211248.l4LCmeIf016998@inana.itg.state.mn.us> <4651F323.9070001@bogus.com> Message-ID: <200705212051.l4LKpTch019652@inana.itg.state.mn.us> ... > So, if we had to support IPv6 tomorrow, we couldn't: the products that > we need to run the network don't exist yet. There are a vast trove of management tools that support ipv6 developed by opensource software developers and network admins over the course of that last decade of managing ipv6 networks. Understood. But, do you really want to tie the success of IPv6 to getting lots of large organizations converting from proprietary tools to open source tools? (Not that that isn't a worthwhile battle in and of itself.) Craig From billf at powerset.com Mon May 21 17:00:11 2007 From: billf at powerset.com (bill fumerola) Date: Mon, 21 May 2007 14:00:11 -0700 Subject: [ppml] getting converts to V6 In-Reply-To: <200705212051.l4LKpTch019652@inana.itg.state.mn.us> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <4650D2EC.5000002@spaghetti.zurich.ibm.com> <46511682.3050902@Dilkie.com> <200705211248.l4LCmeIf016998@inana.itg.state.mn.us> <4651F323.9070001@bogus.com> <200705212051.l4LKpTch019652@inana.itg.state.mn.us> Message-ID: <20070521210011.GH31238@elvis.mu.org> On Mon, May 21, 2007 at 03:51:29PM -0500, Craig Finseth wrote: > Understood. But, do you really want to tie the success of IPv6 to > getting lots of large organizations converting from proprietary tools > to open source tools? (Not that that isn't a worthwhile battle in and > of itself.) there is a vast array of applications, both oss and commercial listed at: http://www.ipv6-to-standard.org/ it even lists an ipv6 fridge[1]. i hope this will quell some of the "no application support!" points beind made here. -- billf@{freebsd.org,powerset.com} 1. http://www.itworld.com/Net/4057/WaitisoverforIPv6,Ja894/ From stephen at sprunk.org Tue May 22 01:00:15 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 22 May 2007 00:00:15 -0500 Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 References: Message-ID: <019701c79c34$2c4e2620$a4b0df0a@atlanta.polycom.com> Thus spake Anthony A. Crumb > I am sure that I will not be able to justify more than one /48 > globally routable prefix for my US internet presence. Because > the last 64 bits of the address are required for interface > identifiers that only leaves me with 16 bits with which to create > a hierarchical enterprise address allocation model. 16 bit of > subnetting space is not enough to create subnet allocation > model for a large enterprise. If you have a reasonable justification for why you need more bits, ARIN will give them to you. At present, since there are no policy guidelines, ARIN is approving all requests for more than a /48. They are collecting a rationale before doing so to provide the community with information about what future policy should look like, but it currently doesn't factor into the decision process. > When are we going to see an end to the debate over ULA- > Central and ULA-Local? I have been working with RFC4193 > "random" method to create address space for my internal > networks but I do not want to move forward with deployment > until there is some "ratified" RFC in place that helps to guild > my address allocation strategy. To be blunt I don't have time to > go through the effort of building a design just to have to rework > it because the space the RFC4193 defines and ULA-Local > gets broken up and allocated to RIRs, LIRs, ISPs, and or > carriers to hand out as ULA-Central. I want to adopt v6 and > get started but I can't afford false starts and rework. ULA is assigned FC00::/7. ULA Local is defined for FC00::/8, and ULA Central, if it passes, will be FD00::/8. The latter is a potential complement to the former, not a replacement, so you can use ULA Local without any fears of it being "broken up and allocated to RIRs [et al]". 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 iljitsch at muada.com Tue May 22 04:45:12 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 22 May 2007 10:45:12 +0200 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> Message-ID: <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> [Funny those multi-mailinglist threads - I never know in which mailbox they'll congregate!] On 15-mei-2007, at 0:47, Owen DeLong wrote: >>> 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. Don't forget that address space is only useful if it's (almost) universally accepted. This is almost certainly not going to be the case for any type of ULA. Apart from that, I would argue that if you want to make sure that ULAs can't be used as PI, it's beneficial to make sure that there are as many of those block out there as possible, so that the prospect of carrying even a subset of those becomes inpractical. And in my opinion, there is no reason to involve the RIRs in giving out ULA-c space, as there are no requirements that must be checked. Just make sure the price is high enough that people aren't going to use up excessively large amounts and any domain registry/registrar should be able to give those out. Something like 5 euros per year should make sure people won't register millions of them without creating a barrier for those who need ULA space and prefer the centrally assigned kind. >> 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. If you can get 5% of the internet population to boycott routable ULAs that makes them unusable as such so this won't be a problem. From iljitsch at muada.com Tue May 22 04:51:19 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 22 May 2007 10:51:19 +0200 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: Message-ID: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: > And the only way to control ULA-central is to have it within the > RIR system, How would that work in practice? Approximately 100% of all organizations use RFC 1918 space. Obviously one use for RFC 1918 space goes away with IPv6 (NAT) but I'd say that the number of internet users requiring some kind of local addressing will still be 10, 20, 30 or more percent. The RIR membership is measured in thousands. So tens of thousands or even hundreds of thousands of organizations that may want ULA-c space have no relationship with an RIR. They may not even have a relationship with an ISP... So how are the RIRs supposed to manage their relationship with 10 or 100 times as many people as they have relationships with now? From iljitsch at muada.com Tue May 22 05:02:06 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 22 May 2007 11:02:06 +0200 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: On 15-mei-2007, at 11:47, Nick Hilliard wrote: > 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? I wanted to keep my 3ffe block in the air as long as possible to see what would happen. Unfortunately, my ISP stopped routing it almost immediately and I was dead in the water... I was surprised to see how fast all of this went down. From jeroen at unfix.org Tue May 22 05:15:18 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 22 May 2007 10:15:18 +0100 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> <20070515093448.GA28881@vacation.karoshi.com.> <464981B0.2040303@inex.ie> Message-ID: <4652B4A6.2020702@spaghetti.zurich.ibm.com> Iljitsch van Beijnum wrote: > On 15-mei-2007, at 11:47, Nick Hilliard wrote: > >> 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? > > I wanted to keep my 3ffe block in the air as long as possible to see > what would happen. Unfortunately, my ISP stopped routing it almost > immediately and I was dead in the water... I was surprised to see how > fast all of this went down. As with everything in that order, see either RIS (http://ris.ripe.net) or of course http://www.sixxs.net/tools/grh/dfp/6bone/ Both 3ffe::/24 and 3ffe:800::/24 are still being announced by Bill Manning, the rest died off quite quickly in the week after Greets, Jeroen -- GRH 6bone list sorted: 2007-05-22 2 <-- still alive 2007-02-16 1 2006-12-15 1 2006-12-14 1 2006-10-07 1 2006-09-19 1 2006-07-29 1 2006-07-18 1 2006-07-08 1 2006-06-30 1 2006-06-26 1 2006-06-21 1 2006-06-19 1 2006-06-16 1 2006-06-15 2 2006-06-13 2 2006-06-12 1 2006-06-08 3 2006-06-07 11 2006-06-06 23 <-- 6GONE date 2006-06-05 1 2006-06-01 2 2006-05-30 1 2006-05-29 1 2006-05-24 2 2006-05-17 1 ... lot of other stuff... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jordi.palet at consulintel.es Tue May 22 09:52:41 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 22 May 2007 09:52:41 -0400 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> Message-ID: It is a matter of having the same organization that allocated IP addresses doing allocation of IP addresses, despite the number of "possible customers", instead of having a *new* organization doing so. I really think it may become a political issue and breach for the RIRs system and I don't feel very comfortable with that. The allocation of the ULA-central addresses can be managed in a very automated way, so not a big issue if really becomes a "big" number of them (which I'm convinced will be the case, because only some big entities may want to avoid using ULA local, but enough to avoid wasting global unicast instead). Regards, Jordi > De: Iljitsch van Beijnum > Responder a: > Fecha: Tue, 22 May 2007 10:51:19 +0200 > Para: > CC: , "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs > NAT in arstechnica (seen on slashdot) > > On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: > >> And the only way to control ULA-central is to have it within the >> RIR system, > > How would that work in practice? Approximately 100% of all > organizations use RFC 1918 space. Obviously one use for RFC 1918 > space goes away with IPv6 (NAT) but I'd say that the number of > internet users requiring some kind of local addressing will still be > 10, 20, 30 or more percent. The RIR membership is measured in > thousands. So tens of thousands or even hundreds of thousands of > organizations that may want ULA-c space have no relationship with an > RIR. They may not even have a relationship with an ISP... > > So how are the RIRs supposed to manage their relationship with 10 or > 100 times as many people as they have relationships with now? > > ********************************************** 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 BillD at cait.wustl.edu Tue May 22 10:08:59 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 22 May 2007 09:08:59 -0500 Subject: [ppml] Notice: ARIN AC Disposition of IPv4 Soft Landing policy proposal Message-ID: Hello, The ARIN Advisory Council at its May 17 meeting chose to 'work with the author', David Conrad, to potentially modify the IPv4 Soft Landing policy proposal rather than accept it 'as is'. This AC decision was based upon the ppml discussion leading up the AC meeting on May 17. David Conrad has agreed to rework the policy proposal to incorporate feedback from the ppml, ARIN staff and ARIN counsel and the AC. Following was the analysis presented and forming the basis for the AC determination. ************************* PPML summary: In excess of 60 (mostly) relevant postings from about 20 entities (as of 1pm Central) Declarations: For - 4 Against - 4 On the fence - 1 Primary points: Staging provides gradual and transparent increases in v4 efficiency requirements and v6 engagement. Looks to be too many stages given 'new' end-date provided by Geoff Huston (31 Dec '09) - this view supported by author Is it even needed, or can it work given current end-date suggested by Geoff Huston? Be better to abandon proposal and focus on educational outreach and 'tools' to support v6 adoption Focuses ISP only - author said he could include enduser portion by popular demand, didn't seem to be much 'Forces' the investment of ISPs in v6 infrastructure and perhaps marketing to get new ration of v4 - is this pressure part of ARIN's charter? Proposal may need to be global policy with some skepticism that all regions would adopt same-text policy in (at least) a timely fashion Suggestion that ARIN or 3rd party would do a formalized audit with majority opinion that requester would pay Cost of audit might make expensive secondary market for IPv4 more reasonable...issue of auditor certification issues raised Concern that implementation might cause ARIN to review previous allocations in light of IPv6 hurdles as part of a reclamation program Suggestion that if/when edits to proposal are finished, a ppml 'survey' should be used to get better sense of consensus - author agrees Proposal as is, has adequate clarity of proposal statement and rationale and is from an author likely to present it personally Author also seems willing to rewrite to increase acceptance/appropriateness My recommendation to AC: Work with the author - given the interest in this topic overall Considerations to abandon: Legal issues surrounding audit and requiring ISP to adopt a technology they are not asking for. Possibly outside the scope of ARIN's role of number resource stewards. Impractical if it cannot be adopted globally in similar fashion. May be better addressed by educational and media outreach. ***************************** Thank you all for your interest an involvement with ARIN public policy evaluation. Please continue to express your opinions and suggestions on how the IPv4 Soft Landing proposal could be modified to make it most valuable to the community. And, the Advisory Council will be most appreciative of your declaration For or Against the proposal as this helps removes subjective assessment of consensus. Bill Darte ARIN AC and Policy proposal shepherd for IPv4 Soft Landing -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmanning at karoshi.com Tue May 22 11:24:06 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 22 May 2007 15:24:06 +0000 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> Message-ID: <20070522152406.GA25888@vacation.karoshi.com.> On Tue, May 22, 2007 at 10:45:12AM +0200, Iljitsch van Beijnum wrote: > > Don't forget that address space is only useful if it's (almost) > universally accepted. that is hardly true. > Just make sure the price is high enough that people aren't going to > use up excessively large amounts and any domain registry/registrar > should be able to give those out. selling numbers eh? thats a neat trick. will RIPE sell me address space? --bill From randy at psg.com Tue May 22 11:41:35 2007 From: randy at psg.com (Randy Bush) Date: Tue, 22 May 2007 11:41:35 -0400 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46530D48.1060803@inex.ie> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> <20070522152406.GA25888@vacation.karoshi.com.> <46530D48.1060803@inex.ie> Message-ID: <46530F2F.2050400@psg.com> > 4 years from now, there will be an active IPv4 address space market, > whatever about ipv6. bingo! what amazes me is the lack of real work on the problem that a a jillion v6-only sites can not connect to the internet in a useful scalable way. without that, everyone will continue to need ipv4 space for a loooooong time. and it will be sliced and diced, and bought and sold, in smaller and smaller pieces. and nats will be ubiquitous, as if they were not already. this is not a pleasing picture. but it's the likely reality. randy From bmanning at karoshi.com Tue May 22 11:45:30 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 22 May 2007 15:45:30 +0000 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46530D48.1060803@inex.ie> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> <20070522152406.GA25888@vacation.karoshi.com.> <46530D48.1060803@inex.ie> Message-ID: <20070522154530.GB25888@vacation.karoshi.com.> On Tue, May 22, 2007 at 04:33:28PM +0100, Nick Hilliard wrote: > bmanning at karoshi.com wrote: > > selling numbers eh? thats a neat trick. will RIPE sell me address > > space? > > 4 years from now, there will be an active IPv4 address space market, > whatever about ipv6. sucker bet. :) there is already an active IPv4 address space market. --bill > > Nick > > -- > Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 > 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 > Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From owen at delong.com Tue May 22 11:48:33 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 22 May 2007 08:48:33 -0700 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> Message-ID: <47C380E7-AF3C-47DF-A0DC-C60BA39989DC@delong.com> On May 22, 2007, at 1:51 AM, Iljitsch van Beijnum wrote: > On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: > >> And the only way to control ULA-central is to have it within the >> RIR system, > > How would that work in practice? Approximately 100% of all > organizations use RFC 1918 space. Obviously one use for RFC 1918 > space goes away with IPv6 (NAT) but I'd say that the number of > internet users requiring some kind of local addressing will still be > 10, 20, 30 or more percent. The RIR membership is measured in > thousands. So tens of thousands or even hundreds of thousands of > organizations that may want ULA-c space have no relationship with an > RIR. They may not even have a relationship with an ISP... > First of all, at least in the case of ARIN, membership is not a requirement for obtaining Address space. I realize that in RIPE and APNIC, membership is required. However, nobody actually NEEDS local addressing, technically. Technically, people NEED addressing. The distinction between local and global addressing is mostly an administrative convenience. There is no local addressing purpose for which global addresses are inadequate or infeasible. I'm quite sure that the RIRs can handle additional business relationships just fine. If someone has neither a relationship with an ISP nor a relationship with an RIR, then, one of those two things will have to change before they get addresses assigned. Same way things work today, except for RFC-1918 and ULA-Local. > So how are the RIRs supposed to manage their relationship with 10 or > 100 times as many people as they have relationships with now? > Same way they do now. Might require beefier or more servers, and an increased staff, but, I would expect that with 10-100 times the fees rolling in, that won't be a problem. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From lincoln at voxeo.com Tue May 22 12:21:49 2007 From: lincoln at voxeo.com (Lincoln Anthony) Date: Tue, 22 May 2007 12:21:49 -0400 Subject: [ppml] PPML Digest, Vol 23, Issue 57 In-Reply-To: References: Message-ID: <1179850910.5456.6.camel@zephyr> Let's take him off the list. On Tue, 2007-05-22 at 12:00 -0400, ppml-request at arin.net wrote: > Send PPML mailing list submissions to > ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/ppml > or, via email, send a message with subject or body 'help' to > ppml-request at arin.net > > You can reach the person managing the list at > ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of PPML digest..." > > > Today's Topics: > > 1. Notice: ARIN AC Disposition of IPv4 Soft Landing policy > proposal (Bill Darte) > 2. Re: [address-policy-wg] Re: article about IPv6 vs firewalls > vs NAT in arstechnica (seen on slashdot) (bmanning at karoshi.com) > 3. Re: [address-policy-wg] Re: article about IPv6 vs firewalls > vs NAT in arstechnica (seen on slashdot) (Randy Bush) > 4. Re: [address-policy-wg] Re: article about IPv6 vs firewalls > vs NAT in arstechnica (seen on slashdot) (bmanning at karoshi.com) > 5. Re: [address-policy-wg] Re: article about IPv6 vs firewalls > vs NAT in arstechnica (seen on slashdot) (Owen DeLong) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 May 2007 09:08:59 -0500 > From: "Bill Darte" > Subject: [ppml] Notice: ARIN AC Disposition of IPv4 Soft Landing > policy proposal > To: > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Hello, > > The ARIN Advisory Council at its May 17 meeting chose to 'work with the > author', David Conrad, to potentially modify the IPv4 Soft Landing > policy proposal rather than accept it 'as is'. This AC decision was > based upon the ppml discussion leading up the AC meeting on May 17. > > David Conrad has agreed to rework the policy proposal to incorporate > feedback from the ppml, ARIN staff and ARIN counsel and the AC. > > Following was the analysis presented and forming the basis for the AC > determination. > > ************************* > PPML summary: > In excess of 60 (mostly) relevant postings from about 20 entities (as of > 1pm Central) > > Declarations: > For - 4 > Against - 4 > On the fence - 1 > > Primary points: > Staging provides gradual and transparent increases in v4 efficiency > requirements and v6 engagement. > Looks to be too many stages given 'new' end-date provided by Geoff > Huston (31 Dec '09) - this view supported by author > Is it even needed, or can it work given current end-date suggested by > Geoff Huston? > Be better to abandon proposal and focus on educational outreach and > 'tools' to support v6 adoption > Focuses ISP only - author said he could include enduser portion by > popular demand, didn't seem to be much > 'Forces' the investment of ISPs in v6 infrastructure and perhaps > marketing to get new ration of v4 - is this pressure part of ARIN's > charter? > Proposal may need to be global policy with some skepticism that all > regions would adopt same-text policy in (at least) a timely fashion > Suggestion that ARIN or 3rd party would do a formalized audit with > majority opinion that requester would pay > Cost of audit might make expensive secondary market for IPv4 more > reasonable...issue of auditor certification issues raised > Concern that implementation might cause ARIN to review previous > allocations in light of IPv6 hurdles as part of a reclamation program > Suggestion that if/when edits to proposal are finished, a ppml 'survey' > should be used to get better sense of consensus - author agrees > > Proposal as is, has adequate clarity of proposal statement and rationale > and is from an author likely to present it personally > Author also seems willing to rewrite to increase > acceptance/appropriateness > > My recommendation to AC: Work with the author - given the interest in > this topic overall > > Considerations to abandon: Legal issues surrounding audit and requiring > ISP to adopt a technology they are not asking for. Possibly outside the > scope of ARIN's role of number resource stewards. Impractical if it > cannot be adopted globally in similar fashion. May be better addressed > by educational and media outreach. > ***************************** > > Thank you all for your interest an involvement with ARIN public policy > evaluation. Please continue to express your opinions and suggestions on > how the IPv4 Soft Landing proposal could be modified to make it most > valuable to the community. And, the Advisory Council will be most > appreciative of your declaration For or Against the proposal as this > helps removes subjective assessment of consensus. > > > Bill Darte > ARIN AC and > Policy proposal shepherd for IPv4 Soft Landing > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.arin.net/pipermail/ppml/attachments/20070522/50a59139/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Tue, 22 May 2007 15:24:06 +0000 > From: bmanning at karoshi.com > Subject: Re: [ppml] [address-policy-wg] Re: article about IPv6 vs > firewalls vs NAT in arstechnica (seen on slashdot) > To: Iljitsch van Beijnum > Cc: ARIN PPML , address-policy-wg at ripe.net > Message-ID: <20070522152406.GA25888 at vacation.karoshi.com.> > Content-Type: text/plain; charset=us-ascii > > On Tue, May 22, 2007 at 10:45:12AM +0200, Iljitsch van Beijnum wrote: > > > > Don't forget that address space is only useful if it's (almost) > > universally accepted. > > that is hardly true. > > > Just make sure the price is high enough that people aren't going to > > use up excessively large amounts and any domain registry/registrar > > should be able to give those out. > > selling numbers eh? thats a neat trick. will RIPE sell me address > space? > > --bill > > > ------------------------------ > > Message: 3 > Date: Tue, 22 May 2007 11:41:35 -0400 > From: Randy Bush > Subject: Re: [ppml] [address-policy-wg] Re: article about IPv6 vs > firewalls vs NAT in arstechnica (seen on slashdot) > To: Nick Hilliard > Cc: ARIN PPML , address-policy-wg at ripe.net > Message-ID: <46530F2F.2050400 at psg.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > 4 years from now, there will be an active IPv4 address space market, > > whatever about ipv6. > > bingo! > > what amazes me is the lack of real work on the problem that a a jillion > v6-only sites can not connect to the internet in a useful scalable way. > without that, everyone will continue to need ipv4 space for a loooooong > time. and it will be sliced and diced, and bought and sold, in smaller > and smaller pieces. and nats will be ubiquitous, as if they were not > already. this is not a pleasing picture. but it's the likely reality. > > randy > > > ------------------------------ > > Message: 4 > Date: Tue, 22 May 2007 15:45:30 +0000 > From: bmanning at karoshi.com > Subject: Re: [ppml] [address-policy-wg] Re: article about IPv6 vs > firewalls vs NAT in arstechnica (seen on slashdot) > To: Nick Hilliard > Cc: ARIN PPML , address-policy-wg at ripe.net > Message-ID: <20070522154530.GB25888 at vacation.karoshi.com.> > Content-Type: text/plain; charset=us-ascii > > On Tue, May 22, 2007 at 04:33:28PM +0100, Nick Hilliard wrote: > > bmanning at karoshi.com wrote: > > > selling numbers eh? thats a neat trick. will RIPE sell me address > > > space? > > > > 4 years from now, there will be an active IPv4 address space market, > > whatever about ipv6. > > sucker bet. :) > there is already an active IPv4 address space market. > > --bill > > > > > Nick > > > > -- > > Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 > > 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 > > Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie > > > ------------------------------ > > Message: 5 > Date: Tue, 22 May 2007 08:48:33 -0700 > From: Owen DeLong > Subject: Re: [ppml] [address-policy-wg] Re: article about IPv6 vs > firewalls vs NAT in arstechnica (seen on slashdot) > To: Iljitsch van Beijnum > Cc: ppml at arin.net, "address-policy-wg at ripe.net" > > Message-ID: <47C380E7-AF3C-47DF-A0DC-C60BA39989DC at delong.com> > Content-Type: text/plain; charset="us-ascii" > > > On May 22, 2007, at 1:51 AM, Iljitsch van Beijnum wrote: > > > On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: > > > >> And the only way to control ULA-central is to have it within the > >> RIR system, > > > > How would that work in practice? Approximately 100% of all > > organizations use RFC 1918 space. Obviously one use for RFC 1918 > > space goes away with IPv6 (NAT) but I'd say that the number of > > internet users requiring some kind of local addressing will still be > > 10, 20, 30 or more percent. The RIR membership is measured in > > thousands. So tens of thousands or even hundreds of thousands of > > organizations that may want ULA-c space have no relationship with an > > RIR. They may not even have a relationship with an ISP... > > > First of all, at least in the case of ARIN, membership is not a > requirement > for obtaining Address space. I realize that in RIPE and APNIC, > membership is required. However, nobody actually NEEDS local > addressing, technically. Technically, people NEED addressing. > The distinction between local and global addressing is mostly > an administrative convenience. There is no local addressing purpose > for which global addresses are inadequate or infeasible. > > I'm quite sure that the RIRs can handle additional business > relationships > just fine. If someone has neither a relationship with an ISP nor a > relationship with an RIR, then, one of those two things will have > to change before they get addresses assigned. Same way things > work today, except for RFC-1918 and ULA-Local. > > So how are the RIRs supposed to manage their relationship with 10 or > > 100 times as many people as they have relationships with now? > > > Same way they do now. Might require beefier or more servers, and an > increased staff, but, I would expect that with 10-100 times the fees > rolling > in, that won't be a problem. > > Owen > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 2105 bytes > Desc: not available > Url : http://lists.arin.net/pipermail/ppml/attachments/20070522/ee8a1a90/smime-0001.bin > > ------------------------------ > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > > End of PPML Digest, Vol 23, Issue 57 > ************************************ From Dan.Thorson at seagate.com Tue May 22 13:53:52 2007 From: Dan.Thorson at seagate.com (Dan.Thorson at seagate.com) Date: Tue, 22 May 2007 12:53:52 -0500 Subject: [ppml] OT: Guidance for multihomed enterprise and IPV6 In-Reply-To: Message-ID: I understand this is off-topic, but I feel confident I'll get some good advise off-list, and so please forgive my transgression: I need some guidence re: deploying IPv6 in a multi-homed multinational enterprise corporation, specifically ensuring global routability and global Internet access failover? Clearly I need IPv6 space which can be announced to multiple ISP's located world-wide.... Again, a continued conversation off-list, or pointers to on-line resources, would be most appropriate/appreciated. danT =================================================== Dan Thorson - Seagate Technology - CCIE 10754 desk +1 (952) 402-8293 fax +1 (952) 402-1007 SeaTel 8-402-8293 =================================================== From jlewis at lewis.org Tue May 22 14:09:46 2007 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 22 May 2007 14:09:46 -0400 (EDT) Subject: [ppml] IPv6 annual fee waivers Message-ID: It seems several times the ARIN BoT has extended the IPv6 fee waiver. I just started looking at the ARIN web site to see what would be involved in getting an IPv6 allocation to start playing around with, and the first thing I noticed was the annual fee waiver expires again in December of this year. After that, barring another fee waiver extension, we'll be paying an additional couple thousand a year for IPv6 address space we're probably not going to be using to generate any revenue. Has any consideration been given to making the annual fee for ARIN IP space whichever of the IPv4 or IPv6 fees for a particular organization is greater? i.e. We currently pay $4500/year for IPv4 space. If we were to get an IPv6 /32, the annual fee for that is $2250. But since we're already paying $4500, the $2250 gets waived. Charging each ARIN member an additional couple thousand a year (or even just the threat of it by continually extending the IPv6 fee waiver a year at a time) is, IMO, not conducive to encouraging ISPs to start learning to use and deploy IPv6. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jeroen at unfix.org Tue May 22 14:14:33 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 22 May 2007 19:14:33 +0100 Subject: [ppml] OT: Guidance for multihomed enterprise and IPV6 In-Reply-To: References: Message-ID: <46533309.5010506@spaghetti.zurich.ibm.com> Dan.Thorson at seagate.com wrote: > I understand this is off-topic, but I feel confident I'll get some good= > advise off-list, and so please forgive my transgression: >=20 > I need some guidence re: deploying IPv6 in a multi-homed multinational > enterprise corporation, specifically ensuring global routability and gl= obal > Internet access failover? Clearly I need IPv6 space which can be annou= nced > to multiple ISP's located world-wide.... For the ARIN region this is quite simple: http://www.arin.net/registration/guidelines/ipv6_assignment.html Fill in the forms, justify the need you have and it's almost presto. At least that is the part of getting address space, where you can go 2 routes: firstly a /48 "PI" and/or a larger (upto /40) PI block. The other depends really on the size of your organization and the way it is structured. If you have an organization which acts like an ISP, and thus providing connectivity to various business units, locations etc, then you can, under certain circumstances, be considered to be an ISP, which allows you to get a /32. Now the real question you most likely have is: You have a location in the US, you have a location in Tokio and one in Amsterdam. Now if you get say a /40, you are supposed to announce it as 1 /40, but that will cause traffic for the US to get routed to Tokio when it originates from there. And in Tokio you might not have a big link and certainly do not want to pull the traffic over your own internal network to the US. Two solutions: announce /48's, or just get separate /48's in the first place. Other solutions are currently (afaik ;) not available though. As you mentioned the "failover" component in all cases is bog-standard BG= P. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From tony at lava.net Tue May 22 14:37:50 2007 From: tony at lava.net (Antonio Querubin) Date: Tue, 22 May 2007 08:37:50 -1000 (HST) Subject: [ppml] OT: Guidance for multihomed enterprise and IPV6 In-Reply-To: <46533309.5010506@spaghetti.zurich.ibm.com> References: <46533309.5010506@spaghetti.zurich.ibm.com> Message-ID: On Tue, 22 May 2007, Jeroen Massar wrote: > Dan.Thorson at seagate.com wrote: >> I need some guidence re: deploying IPv6 in a multi-homed multinational >> enterprise corporation, specifically ensuring global routability and gl= > obal >> Internet access failover? Clearly I need IPv6 space which can be annou= > nced >> to multiple ISP's located world-wide.... > For the ARIN region this is quite simple: > > http://www.arin.net/registration/guidelines/ipv6_assignment.html He needs global routability. A direct assignment doesn't get that but an allocation will. http://www.arin.net/registration/guidelines/ipv6_initial_alloc.html Antonio Querubin whois: AQ7-ARIN From jeroen at unfix.org Tue May 22 14:46:46 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 22 May 2007 19:46:46 +0100 Subject: [ppml] OT: Guidance for multihomed enterprise and IPV6 In-Reply-To: References: <46533309.5010506@spaghetti.zurich.ibm.com> Message-ID: <46533A96.10105@spaghetti.zurich.ibm.com> Antonio Querubin wrote: > On Tue, 22 May 2007, Jeroen Massar wrote: > >> Dan.Thorson at seagate.com wrote: > >>> I need some guidence re: deploying IPv6 in a multi-homed multinational >>> enterprise corporation, specifically ensuring global routability and gl= >> obal >>> Internet access failover? Clearly I need IPv6 space which can be annou= >> nced >>> to multiple ISP's located world-wide.... > >> For the ARIN region this is quite simple: >> >> http://www.arin.net/registration/guidelines/ipv6_assignment.html > > He needs global routability. A direct assignment doesn't get that but > an allocation will. How exactly does a direct assignment not 'get' the 'global routability' part? Can you elaborate? Please first check: http://www.sixxs.net/tools/grh/dfp/arin/ and see all the blocks under 2620::/32. I have to agree, they only have ~86% reachability, but that is mostly due to missing transit providers and of course some ASNs still filter them out. But they definitely give you 'global routability'. (Though even ULA's or any other random number would give you that as long as your resource is either important enough or you donate enough money to folks to get it accepted) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From iljitsch at muada.com Tue May 22 14:51:39 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 22 May 2007 20:51:39 +0200 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46530F2F.2050400@psg.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> <20070522152406.GA25888@vacation.karoshi.com.> <46530D48.1060803@inex.ie> <46530F2F.2050400@psg.com> Message-ID: On 22-mei-2007, at 17:41, Randy Bush wrote: >> 4 years from now, there will be an active IPv4 address space market, >> whatever about ipv6. > bingo! ...and that will be the fastest way to kill the remaining v4 space. Triple word value! > what amazes me is the lack of real work on the problem that a a > jillion > v6-only sites can not connect to the internet in a useful scalable > way. Interconnection between IPv6 clients and IPv4 servers can work very well and it can be done at three layers: - application - transport - network At the application layer we have proxies. The problem is that applications need to be aware of them and you need different proxies for different applications. However, pretty much any client-to-server TCP application can make use of the CONNECT method created for HTTPS proxying without the proxy having to be aware of the application protocol. At the transport layer you can have a TCP relay with a DNS ALG, serves the same function as a CONNECT proxy but without the app having to know about it. Not widely implemented, though. And for the network layer the IETF defined NAT-PT (network address translation - protocol translation) which translates between IPv6 and IPv4 and performs IPv4 NAT. Haven't tested this myself due to lack of implementations I could get my hands on and then the IETF decided this wasn't a good idea after all so NAT-PT is either already gone or on the way out. So the good news is that it's fairly trivial to support IPv6-only clients if you have a dual stack proxy and mail server. This takes care of HTTP (90% of all apps right there), HTTPS, mail and basic IM functionality. There are two flavors of peer-to-peer. The first one is towards specific peers, such as with VoIP, so you either need to wait for everyone to have IPv6 or have application-specific proxies. The second type is towards any reasonable subset of a lot of peers, such as BitTorrent. You don't care which peers you talk to, as long as it's enough to get the file. So what you need here is a reasonable subset of peers that are dual stack to facilitate the movement of bits between IPv6-only and IPv4-only peers. There's also often a server or tracker, which would have to be proxied or dual stack. There you have it. You can actually run IPv6-only and get work done, even with the current state of affairs. From Alain_Durand at cable.comcast.com Tue May 22 16:19:44 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Tue, 22 May 2007 16:19:44 -0400 Subject: [ppml] Arguments against Policy Proposal: IPv4 Soft Landing In-Reply-To: <3095BF3B-CDAA-4FD2-AF3C-357B05486B98@virtualized.org> Message-ID: I would like to articulate several points against the IPv4 soft landing proposal. 1) This might be just too late to be effective give current projected end date In practice, there could be only 1 or 2 steps, no more. 2) This creates an increase risk of a 'run to the bank' before the current set of policies change 3) Increasing allocation efficiency comes with a cost. This will mean smaller and smaller prefixes will have to be routed 4) Efficiency above 80%. For an organization that does allocation from fairly large blocks all the way up to end devices , 80% efficiency is already a very high tartget to achieve and it is not feasable to go much above. We may shoot for 81 or 82% with great difficulties, but 90% and above is irrealistic. 5) "Recycling of x% of IPv4 address space formerly used for internal infrastructure" This may simply not be feasable. A large number of infrastructure devices are not upgradable to IPv6 due to physical constraints (eg: not enough memory). In environments like the one I'm working on, even with the most aggressive IPv6 plans, a very large number of legacy infrastructure devices will never be upgraded to IPv6. The new ones will, not the legacy ones. More generally, I would like to stress that ARIN has no business to mandate that an organization be forced into a hardware change. 6) "* Documented availability of production IPv6 infrastructure services * Documented availability of production IPv6 connectivity service" This doesn't mean very much. Anybody can set up a web server with a 6to4 address and claim it satisfy this requirement! What you would really want is to say something along the lines of the requester should offer IPv6 service on par with IPv4 service But again, this may be problematic for legacy services... so one thing could be to ask that new services offered in IPv4 would also be offered on IPv6... but again, this may be looked as ARIN imposing a particular business model Given all the above points, I'm not in favor of this policy. - Alain. ---------------------------------- Alain Durand Director - IPv6 architect Comcast / Office of the CTO From drc at virtualized.org Tue May 22 17:25:04 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 22 May 2007 14:25:04 -0700 Subject: [ppml] Arguments against Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: <027B687B-50EF-4D02-9EE5-677BEFA1C7E0@virtualized.org> Alain, Thanks for the comments. On May 22, 2007, at 1:19 PM, Durand, Alain wrote: > 1) This might be just too late to be effective give current projected > end date > In practice, there could be only 1 or 2 steps, no more. I'm in the process of revising the number of phases, however I still am of the opinion that projected end dates are largely exercises in deriving random numbers given it is essentially impossible to incorporate socio-economic factors that will likely have significant impact on consumption rates. The reason I have chosen to revise the number of phases (to 4 from 6) is to simplify the policy somewhat. > 2) This creates an increase risk of a 'run to the bank' before > the current set of policies change The IPv4 free pool is nearing exhaustion. Given human nature, a "run on the bank" will almost certainly occur regardless of what policies are imposed and I'm not sure how "Soft Landing" increases this risk. The point of increased requirements such as the 3rd party audit is to reduce the likelihood of people simply making up numbers to get allocations. Will such making up of numbers occur? Sure. Suggestions on how to keep people from making a 'run on the bank' happily accepted (and may be forwarded to the Nobel Prize committee for possible consideration for the award for Economics). > 3) Increasing allocation efficiency comes with a cost. > This will mean smaller and smaller prefixes will have to be routed Yes. This will also almost certainly be occurring regardless of what policies are imposed. A natural outcome of IPv4 free pool exhaustion is that people will notice they have lots of address space they aren't using or could use more efficiently (e.g., MIT) and hence, more specifics from the "legacy" allocations will begin to appear. I would argue that "Soft Landing" is unlikely to have a significant impact on the number of prefixes or that will appear. However, folks at router vendors who can reasonably be assumed to know what they are talking about have indicated that router scalability isn't a concern for 5 to 10 years. While I am not sure I believe them, there is at least some room for argument that the routing system can withstand the flood of longer IPv4 prefixes that will be coming. > 4) Efficiency above 80%. > > For an organization that does allocation from fairly large blocks > all the way up to end devices , 80% efficiency is already a very > high tartget to achieve and it is not feasable to go much above. > We may shoot for 81 or 82% with great difficulties, but 90% and > above is irrealistic. I would be interested in understanding this point more, perhaps privately. I do not have enough data to fully appreciate your concerns here. However, the IPv4 free pool is nearing exhaustion so it is unlikely that the processes and procedures used when IPv4 was plentiful will continue to be appropriate. > 5) "Recycling of x% of IPv4 address space formerly used for internal > infrastructure" > > This may simply not be feasable. A large number of infrastructure > devices are not upgradable to IPv6 due to physical constraints > (eg: not enough memory). In environments like the one I'm working > on, even with the most aggressive IPv6 plans, a very large number > of legacy infrastructure devices will never be upgraded to IPv6. > The new ones will, not the legacy ones. In such cases, is there a reason you cannot use RFC 1918 for the legacy devices? > More generally, I would like to stress that ARIN has no business > to mandate that an organization be forced into a hardware change. Then you have concerns about the liberalization of PI allocation policies since they're going to cause ISPs to upgrade their hardware? I agree the policy cannot mandate a hardware change and, in fact, it does not do so. ARIN may, however, impose policies that may best (but not exclusively) be met by upgrading hardware infrastructure. The IPv4 free pool is nearing exhaustion, thus new allocations of that scarce resource should be reserved for the most critical needs and efforts should be undertaken to reuse inefficiently used previous allocations where possible. > 6) "* Documented availability of production IPv6 infrastructure > services > * Documented availability of production IPv6 connectivity > service" > > This doesn't mean very much. Anybody can set up a web server > with a 6to4 address and claim it satisfy this requirement! Yes. Presumably, the mechanisms ARIN staff use to determine conformance to this requirement would be able to discern between folks who are pretending to meet the requirement and those who do meet the requirement. However, I do not believe the mechanisms should be specified in the policy. > What you would really want is to say something along the lines > of the requester should offer IPv6 service on par with IPv4 > service I do not believe ARIN can mandate exactly what services are provided or how they are provided. I personally do not believe there will be a one-to-one mapping between IPv4 and IPv6 services. The best we can hope for is that the deployment of _some_ IPv6 services will trigger the deployment of sufficient IPv6 infrastructure to allow us to migrate in a reasonable fashion. > Given all the above points, I'm not in favor of this policy. Understood. However, given the IPv4 free pool is nearing exhaustion, I would be interested in understanding what your view of the alternatives are. Rgds, -drc From jrhett at svcolo.com Tue May 22 17:56:21 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 22 May 2007 14:56:21 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <005b01c78a87$0edf4600$08067126@basespacenf1s7> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <005b01c78a87$0edf4600$08067126@basespacenf1s7> Message-ID: <7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com> On Apr 29, 2007, at 10:51 AM, Alex wrote: > Actually, no, not the only reason, just one reason. The main reason > I would > like PI space is so that I can excercise freedom of choice among > upstream > ISPs without having to renumber, and so that I will not again be in > danger > of losing my livelihood when my upstream goes out of business or is > bought. If you are in danger of losing your livelihood because of a forced renumber, then you need to determine what about your business creates that dependancy and fix it. Renumbering is fairly trivial. This whole idea that renumbering is painful and difficult has no basis in reality except for people who hardcode IP addresses into their applications, and ARIN does not have to accept ridiculous actions like that. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From tony at lava.net Tue May 22 18:01:28 2007 From: tony at lava.net (Antonio Querubin) Date: Tue, 22 May 2007 12:01:28 -1000 (HST) Subject: [ppml] OT: Guidance for multihomed enterprise and IPV6 In-Reply-To: <46533A96.10105@spaghetti.zurich.ibm.com> References: <46533309.5010506@spaghetti.zurich.ibm.com> <46533A96.10105@spaghetti.zurich.ibm.com> Message-ID: On Tue, 22 May 2007, Jeroen Massar wrote: > How exactly does a direct assignment not 'get' the 'global routability' > part? Can you elaborate? Just going by ARIN's wording: "Typically, end-users receive IPv6 addresses from an Internet Service Provider (ISP), not directly from ARIN. Assigned addresses obtained directly from ARIN are the least likely to be globally routable." Also, the size of the assignment is a /48. A lot of folks are filtering outgoing announcements of anything longer than /32 in many cases to enforce aggregation policies. So in this particular case where global reachability for multiple multi-homed sites is a must, it sounds like a direct assignment is really not suitable. Multiple direct assignment /48s might get closer to the desired outcome but if the parent organization has a lot of sites to deal with then for all intents and purposes it's an LIR for its remote sites. Antonio Querubin whois: AQ7-ARIN From bmanning at karoshi.com Tue May 22 18:23:17 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 22 May 2007 22:23:17 +0000 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <005b01c78a87$0edf4600$08067126@basespacenf1s7> <7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com> Message-ID: <20070522222317.GB28368@vacation.karoshi.com.> On Tue, May 22, 2007 at 02:56:21PM -0700, Jo Rhett wrote: > On Apr 29, 2007, at 10:51 AM, Alex wrote: > > Actually, no, not the only reason, just one reason. The main reason > > I would > > like PI space is so that I can excercise freedom of choice among > > upstream > > ISPs without having to renumber, and so that I will not again be in > > danger > > of losing my livelihood when my upstream goes out of business or is > > bought. > > If you are in danger of losing your livelihood because of a forced > renumber, then you need to determine what about your business creates > that dependancy and fix it. > > Renumbering is fairly trivial. This whole idea that renumbering is > painful and difficult has no basis in reality except for people who > hardcode IP addresses into their applications, and ARIN does not have > to accept ridiculous actions like that. me: I have spent 650,000 on HP Openview to manage my networks and they code the license key to the IP address of the node. ... I'd really rather not have to renumber and buy new licenses. > -- > Jo Rhett > senior geek > > Silicon Valley Colocation > Support Phone: 408-400-0550 > > > > > _______________________________________________ > 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 jrhett at svcolo.com Tue May 22 18:36:30 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 22 May 2007 15:36:30 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <005b01c78a87$0edf4600$08067126@basespacenf1s7> <7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com> <20070522222317.GB28368@vacation.karoshi.com.> Message-ID: On May 22, 2007, at 3:33 PM, Antonio Querubin wrote: > On Tue, 22 May 2007, bmanning at karoshi.com wrote: >> me: I have spent 650,000 on HP Openview to manage my networks >> and they code the license key to the IP address of the node. >> ... I'd really rather not have to renumber and buy new >> licenses. > > Last time I had to deal with this (or rather people who worked for > me) HP will allow you to update the license without having to buy a > new one just for an IP address change. The downside though is that > I hear it's a really painful process. Painful is getting a lot of use around here, and so far nothing I've seen described strikes me as painful. Last time I redid the HP Openview licenses I did it online, using the HP's license tools, and it took me 5 minutes. 4 minutes of that was logging in and getting to know the tool. I have significantly more frustration in morning traffic ;-) -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jeroen at unfix.org Tue May 22 18:40:13 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 22 May 2007 23:40:13 +0100 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <005b01c78a87$0edf4600$08067126@basespacenf1s7> <7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com> Message-ID: <4653714D.9020500@spaghetti.zurich.ibm.com> Jo Rhett wrote: [..] > If you are in danger of losing your livelihood because of a forced > renumber, then you need to determine what about your business creates > that dependancy and fix it. > > Renumbering is fairly trivial. This whole idea that renumbering is > painful and difficult has no basis in reality except for people who > hardcode IP addresses into their applications, and ARIN does not have > to accept ridiculous actions like that. With absolutely no pun intended, I suggest that ARIN provides you with a new block and takes your existing blocks that you are currently using. Then you can write up a perfect document demonstrating how wrong the rest of the people are who clearly do say that it is extremely painful. What you say? You don't want to renumber? Why that? It was sooo easy. Oh so you actually don't have an automated mechanism to update the glue for all the 10k domains you have, which are not actually fully maintained by you, and thus you have to contact folks to get that fixed. Oh, so you don't have an automated script which reconfigures automatically all the firewalls at all the various companies you work with. Thought so... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From iljitsch at muada.com Tue May 22 18:45:00 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 23 May 2007 00:45:00 +0200 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070522222317.GB28368@vacation.karoshi.com.> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <005b01c78a87$0edf4600$08067126@basespacenf1s7> <7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com> <20070522222317.GB28368@vacation.karoshi.com.> Message-ID: <6649F778-07B3-4A82-B829-F81BAF9E43A6@muada.com> On 23-mei-2007, at 0:23, bmanning at karoshi.com wrote: > me: I have spent 650,000 on HP Openview to manage my networks > and they code the license key to the IP address of the node. > ... I'd really rather not have to renumber and buy new > licenses. You may want to show them the contract you had to sign with ARIN where it states that IP address space isn't property. Interestingly, HP is the single largest user of address space (2 /8s) with the exception of the US government (~ 10 /8s). From jeroen at unfix.org Tue May 22 18:45:23 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 22 May 2007 23:45:23 +0100 Subject: [ppml] OT: Guidance for multihomed enterprise and IPV6 In-Reply-To: References: <46533309.5010506@spaghetti.zurich.ibm.com> <46533A96.10105@spaghetti.zurich.ibm.com> Message-ID: <46537283.6010601@spaghetti.zurich.ibm.com> Antonio Querubin wrote: > On Tue, 22 May 2007, Jeroen Massar wrote: > >> How exactly does a direct assignment not 'get' the 'global routability' >> part? Can you elaborate? > > Just going by ARIN's wording: Where is that wording from? > "Typically, end-users receive IPv6 addresses from an Internet Service > Provider (ISP), not directly from ARIN. Assigned addresses obtained > directly from ARIN are the least likely to be globally routable." None of the RIRs guarantee any routability of any prefix at all. They have programs like the debogon program which might mitigate these effects but for the rest nada. RIRs also _can't_ guarantee this as it is not their network to configure, that is the local policy of that ISP. If some ISP decided to filter out >/16, then that is their policy. > Also, the size of the assignment is a /48. A lot of folks are filtering > outgoing announcements of anything longer than /32 in many cases to > enforce aggregation policies. Did you actually _look_ at the URL's I provided, also in text in the email, showing that 86% of the networks are fine!? For the remained we *know* which sites are wrong, fixing them up requires only that those sites wake up. Nothing bad there. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From Alain_Durand at cable.comcast.com Tue May 22 18:59:43 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Tue, 22 May 2007 18:59:43 -0400 Subject: [ppml] Arguments against Policy Proposal: IPv4 Soft Landing In-Reply-To: <027B687B-50EF-4D02-9EE5-677BEFA1C7E0@virtualized.org> Message-ID: David, I will address the larger issue of IPv4 exhaustion in a later email, just responding to one specific point: > -----Original Message----- > From: David Conrad [mailto:drc at virtualized.org] > > 5) "Recycling of x% of IPv4 address space formerly used for internal > > infrastructure" > > > > This may simply not be feasable. A large number of infrastructure > > devices are not upgradable to IPv6 due to physical constraints > > (eg: not enough memory). In environments like the one I'm working > > on, even with the most aggressive IPv6 plans, a very large number > > of legacy infrastructure devices will never be upgraded to IPv6. > > The new ones will, not the legacy ones. > > In such cases, is there a reason you cannot use RFC 1918 for > the legacy devices? We are using it, but RFC1918 space is too small for our needs. - Alain. From paul at vix.com Tue May 22 19:14:29 2007 From: paul at vix.com (Paul Vixie) Date: Tue, 22 May 2007 23:14:29 +0000 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: Your message of "Tue, 22 May 2007 15:36:30 MST." References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <005b01c78a87$0edf4600$08067126@basespacenf1s7> <7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com> <20070522222317.GB28368@vacation.karoshi.com.> Message-ID: <12533.1179875669@sa.vix.com> > Painful is getting a lot of use around here, and so far nothing I've > seen described strikes me as painful. how about if you have downstreams and when you renumber you have to give each of them a chance to consider changing to a different vendor (possibly one who won't force them to renumber as often)? From vixie at vix.com Tue May 22 19:16:00 2007 From: vixie at vix.com (Paul Vixie) Date: Tue, 22 May 2007 23:16:00 +0000 Subject: [ppml] Arguments against Policy Proposal: IPv4 Soft Landing In-Reply-To: Your message of "Tue, 22 May 2007 18:59:43 -0400." References: Message-ID: <12649.1179875760@sa.vix.com> > > In such cases, is there a reason you cannot use RFC 1918 for > > the legacy devices? > > We are using it, but RFC1918 space is too small for our needs. how much private IPv4 address space would be enough? From jrhett at svcolo.com Tue May 22 19:24:49 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 22 May 2007 16:24:49 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <4653714D.9020500@spaghetti.zurich.ibm.com> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <005b01c78a87$0edf4600$08067126@basespacenf1s7> <7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com> <4653714D.9020500@spaghetti.zurich.ibm.com> Message-ID: On May 22, 2007, at 3:40 PM, Jeroen Massar wrote: > With absolutely no pun intended, I suggest that ARIN provides you > with a > new block and takes your existing blocks that you are currently using. Already did, that's how I can speak from experience. Time-consuming, yes. Detail-oriented, absolutely. Painful? No. IETF process is painful. Trying to keep up with this list is painful. Renumbering is much easier. > What you say? You don't want to renumber? Why that? It was sooo easy. > Oh so you actually don't have an automated mechanism to update the > glue > for all the 10k domains you have, which are not actually fully > maintained by you, and thus you have to contact folks to get that > fixed. > Oh, so you don't have an automated script which reconfigures > automatically all the firewalls at all the various companies you work > with. Thought so... Been through all of that. I can provide exhaustive detail of what I learned from my early mistakes, and what mistakes I've seen others make, and just how trivial they are to avoid these days. Don't be sarcastic to someone when you don't know their background. I won't bother responding to insults, it has never done anything useful in the past and I don't expect it to now. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From scott.beuker at sjrb.ca Tue May 22 19:27:24 2007 From: scott.beuker at sjrb.ca (Scott Beuker) Date: Tue, 22 May 2007 17:27:24 -0600 Subject: [ppml] IPv6 annual fee waivers In-Reply-To: Message-ID: Jon Lewis wrote: > Has any consideration been given to making the annual fee for ARIN IP > space whichever of the IPv4 or IPv6 fees for a particular organization is > greater? i.e. We currently pay $4500/year for IPv4 space. If we were to > get an IPv6 /32, the annual fee for that is $2250. But since we're > already paying $4500, the $2250 gets waived. I think this is the right idea. Scott Beuker Network Architect, IP Backbone Shaw Internet Engineering From iljitsch at muada.com Tue May 22 19:30:10 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 23 May 2007 01:30:10 +0200 Subject: [ppml] Arguments against Policy Proposal: IPv4 Soft Landing In-Reply-To: <027B687B-50EF-4D02-9EE5-677BEFA1C7E0@virtualized.org> References: <027B687B-50EF-4D02-9EE5-677BEFA1C7E0@virtualized.org> Message-ID: <7DA91B2A-B88B-4AC3-B7EF-502ADC1366F9@muada.com> On 22-mei-2007, at 23:25, David Conrad wrote: >> 2) This creates an increase risk of a 'run to the bank' before >> the current set of policies change > The IPv4 free pool is nearing exhaustion. Given human nature, a "run > on the bank" will almost certainly occur So what would that look like? The way I see it, the only people who can successfully request really big blocks of address space, are people who already hold really big blocks of address space, which would be the world's largest ISPs. Anything below a /16 is not worth our time, that's only 15% of the yearly address use. It is, howerver, 91% of the allocations. Reclaiming one or two /8s a year is enough to fulfill the < /16 requests so for people needing less than a /16, IPv4 will effectively never run out. It will for the large ISPs, but does it really matter much in the grand scheme of things whether those play nice or start padding their requests? At some point, they'll have more customers than addresses, and that's the moment of truth. The only people for which all of this really makes a difference is new big address users: those don't have the track record to prove to the RIRs that they really need the addresses, and they don't have large existing address blocks to spread a little thinner over the increasing numbers of customers. > The point of increased requirements such as the 3rd party audit is to > reduce the likelihood of people simply making up numbers to get > allocations. Did you have any request size in mind for this? An audit for a /9 request makes some sense. For a /24 request it's complete overkill. > However, folks at router vendors who can reasonably be assumed to > know what they are talking about have indicated that router > scalability isn't a concern for 5 to 10 years. Not exactly. There are already significant power, cooling and cost issues. Will there be a moment when vendors are going to tell us that there is no way they can build a bigger router? Not likely. But the number of people that can afford the routers they do manage to build will decrease as the routing table grows, as has happened over the past decade. See the results from the IAB routing and addressing workshop last year. >> 4) Efficiency above 80%. >> For an organization that does allocation from fairly large blocks >> all the way up to end devices , 80% efficiency is already a very >> high tartget to achieve and it is not feasable to go much above. >> We may shoot for 81 or 82% with great difficulties, but 90% and >> above is irrealistic. > I would be interested in understanding this point more, perhaps > privately. I do not have enough data to fully appreciate your > concerns here. However, the IPv4 free pool is nearing exhaustion so > it is unlikely that the processes and procedures used when IPv4 was > plentiful will continue to be appropriate. If you have 50 hosts in one subnet you can have a /26 (64 addresses) and have about 80% efficiency. But if you have 500 hosts in 10 subnets, you'll need a /22 (1024 addresses), which allows for 16 /26 subnets even though you only need 10. So at the organization->subnet level you are 10/16 = 62.5% efficient and then 50/64 = 78.125% at the subnet level but your total efficiency is only 500/1024 = 48.8%. In other words, the maximum reasonably reachable efficiency is reduced with each level of hiearchy in your addressing model. For really large networks with a good number of hierarchical levels this adds up quickly. See RFC 3194 that Alain co-wrote. >> Given all the above points, I'm not in favor of this policy. > Understood. However, given the IPv4 free pool is nearing exhaustion, > I would be interested in understanding what your view of the > alternatives are. I can't speak for Alain, but I am also against this policy proposal. My ideal scenario is one where nothing changes, except for a possible gradual increase in the yearly number of address use, so we don't have to keep coming up with new predictions that people are going to ignore if they don't like them. Predictability is key. From jrhett at svcolo.com Tue May 22 19:32:02 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 22 May 2007 16:32:02 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <12533.1179875669@sa.vix.com> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <005b01c78a87$0edf4600$08067126@basespacenf1s7> <7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com> <20070522222317.GB28368@vacation.karoshi.com.> <12533.1179875669@sa.vix.com> Message-ID: <49D13C39-1A8A-4E90-AC28-F42595975B6F@svcolo.com> On May 22, 2007, at 4:14 PM, Paul Vixie wrote: >> Painful is getting a lot of use around here, and so far nothing I've >> seen described strikes me as painful. > > how about if you have downstreams and when you renumber you have to > give > each of them a chance to consider changing to a different vendor > (possibly > one who won't force them to renumber as often)? We're a colo facility, so it's all downstream and yes we've had to face this. I was instrumental in changing our policies to force renumbering *AND* return of the original space, and I've been the point of contact for all the pain. I have personally taken on the migration efforts for those customers, and personally assisted them with the migrations. Nobody here has felt the pain more than me, and frankly there really wasn't all that much. So far it hasn't cost us a single customer, and we're more in danger of filling up our 5th building right now and not having space to sell. Look, IP migration was a pain in the a** when MPE/IX was common and everything was hardcoded. I hated my job during the NAVSEA/Milnet IP migration. But that was nearly 20 years ago, and none of the problems we faced then exist any more. IP migrations are only painful to people who hardcode IPs and then fail to document them as dependancies. And lack of planning isn't really something that ARIN is supposed to provide aspirin for. FYI: there are real situations that renumbering is painful. Paul, I think you've got a few in hand that you can spin out and I can't deny. But they are fairly rare, and a lot less common than how often it has been trotted out on this list. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From alex at basespace.net Tue May 22 20:10:41 2007 From: alex at basespace.net (Alex) Date: Tue, 22 May 2007 20:10:41 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt><005b01c78a87$0edf4600$08067126@basespacenf1s7><7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com><20070522222317.GB28368@vacation.karoshi.com.><12533.1179875669@sa.vix.com> <49D13C39-1A8A-4E90-AC28-F42595975B6F@svcolo.com> Message-ID: <008401c79cce$ccc4bcf0$08067126@basespacenf1s7> > We're a colo facility, so it's all downstream and yes we've had to > face this. > > I was instrumental in changing our policies to force renumbering > *AND* return of the original space, and I've been the point of > contact for all the pain. I have personally taken on the migration > efforts for those customers, and personally assisted them with the > migrations. Nobody here has felt the pain more than me, and frankly > there really wasn't all that much. I am boggled by this assertion. Did you really take responsibility for looking up how to change the IP address on whatever ancient hardware and software each customer had colocated with you? Furthermore, did you not have customers who pushed back on this and were unhappy that you needed to touch their machine? > So far it hasn't cost us a single customer, and we're more in danger > of filling up our 5th building right now and not having space to sell. I congratulate you on your customer service. All I can say is, your experience does not match mine. When I had to renumber, it was painful, and customers were unhappy, and a couple of them did leave shortly thereafter - not of course admitting that the renumbering was the cause. The real question, though, is: are you willing to do it all again every few years when your upstream from whom you get PA space is bought, or changes its prices or its policies? The real problem with lack of PI space is it removes freedom of choice from the little guy, which places negotiating power in the hands of the big upstream providers. From Alain_Durand at cable.comcast.com Tue May 22 21:43:59 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Tue, 22 May 2007 21:43:59 -0400 Subject: [ppml] Arguments against Policy Proposal: IPv4 Soft Landing In-Reply-To: <12649.1179875760@sa.vix.com> Message-ID: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Paul Vixie > > > > In such cases, is there a reason you cannot use RFC 1918 for the > > > legacy devices? > > > > We are using it, but RFC1918 space is too small for our needs. > > how much private IPv4 address space would be enough? It depends on the size of the network. In our case, if we had not been planning for IPv6, I would say probably a /4 would be enough... 240/4 would have been a candidate if it had been usable, unfortunately it is not and will not be in the foreseeable future, so I do not even consider it as an option. Of course, all this assumes that none of those infrastructure piece talk to any other infrastructure piece of another operator, which is not always the case (e.g. VoIP peerings), which lead to yet another reason to use global addresses. - Alain. From drc at virtualized.org Wed May 23 02:37:44 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 22 May 2007 23:37:44 -0700 Subject: [ppml] Arguments against Policy Proposal: IPv4 Soft Landing In-Reply-To: References: Message-ID: <0D7D79FD-0847-46A6-B7A5-DECF0B0646DC@virtualized.org> Alain, On May 22, 2007, at 6:43 PM, Durand, Alain wrote: >> how much private IPv4 address space would be enough? > > It depends on the size of the network. In our case, if we had not > been planning for IPv6, I would say probably a /4 would be enough... I'm a bit confused. You have indicated you have > 16M legacy devices that don't support IPv6 and can't be upgraded. When asked how much additional private space you need, you say if you hadn't been planning for IPv6 then approximately 1/4th the entire IANA free pool would be sufficient to number your internal infrastructure. However, you have been planning for IPv6 so presumably you would require less space. Any idea how much additional IPv4 space you will require to number legacy devices that don't support IPv6 and can't be upgraded? Thanks, -drc From bob at FiberInternetCenter.com Wed May 23 02:55:28 2007 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 22 May 2007 23:55:28 -0700 (PDT) Subject: [ppml] Arguments against Policy Proposal: IPv4 Soft Landing In-Reply-To: <0D7D79FD-0847-46A6-B7A5-DECF0B0646DC@virtualized.org> References: <0D7D79FD-0847-46A6-B7A5-DECF0B0646DC@virtualized.org> Message-ID: <65181.76.204.76.13.1179903328.squirrel@bobevans.net> Wow, 16 Million cable modems that dont support IPv6....It's not hard to imagine...I knew it would happen once TCI got everyone on the docsis band wagon. And it was so obvious back then that TCI was just slowing things up until they could prepare to deploy...it's very likely. bob evans > Alain, > > On May 22, 2007, at 6:43 PM, Durand, Alain wrote: >>> how much private IPv4 address space would be enough? >> >> It depends on the size of the network. In our case, if we had not >> been planning for IPv6, I would say probably a /4 would be enough... > > I'm a bit confused. > > You have indicated you have > 16M legacy devices that don't support > IPv6 and can't be upgraded. When asked how much additional private > space you need, you say if you hadn't been planning for IPv6 then > approximately 1/4th the entire IANA free pool would be sufficient to > number your internal infrastructure. However, you have been planning > for IPv6 so presumably you would require less space. Any idea how > much additional IPv4 space you will require to number legacy devices > that don't support IPv6 and can't be upgraded? > > 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 > > www.FiberInternetCenter.com From drc at virtualized.org Wed May 23 03:10:27 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 23 May 2007 00:10:27 -0700 Subject: [ppml] Arguments against Policy Proposal: IPv4 Soft Landing In-Reply-To: <7DA91B2A-B88B-4AC3-B7EF-502ADC1366F9@muada.com> References: <027B687B-50EF-4D02-9EE5-677BEFA1C7E0@virtualized.org> <7DA91B2A-B88B-4AC3-B7EF-502ADC1366F9@muada.com> Message-ID: <22FC72C5-2EF1-4B91-AE5A-B4269BE4CC81@virtualized.org> Iljitsch, On May 22, 2007, at 4:30 PM, Iljitsch van Beijnum wrote: > The way I see it, the only people who can successfully request > really big blocks of address space, are people who already hold > really big blocks of address space, You believe this because...? >> The point of increased requirements such as the 3rd party audit is to >> reduce the likelihood of people simply making up numbers to get >> allocations. > Did you have any request size in mind for this? An audit for a /9 > request makes some sense. For a /24 request it's complete overkill. I would assume 3rd party audits would be applied fairly to all requesters, but I would also assume this would be at the discretion of ARIN staff. >> However, folks at router vendors who can reasonably be assumed to >> know what they are talking about have indicated that router >> scalability isn't a concern for 5 to 10 years. > > Not exactly > ... > See the results from the IAB routing and addressing workshop last > year. Yes, if you remember, I was there. However, I have also been following subsequent discussions in various places and discussing the situation with folks at router vendors. My statement stands (even though I do not necessarily believe it). >>> 4) Efficiency above 80%. > ... > If you have 50 hosts in one subnet you can have a /26 (64 > addresses) and have about 80% efficiency. But if you have 500 hosts > in 10 subnets, you'll need a /22 (1024 addresses), which allows for > 16 /26 subnets even though you only need 10. So at the organization- > >subnet level you are 10/16 = 62.5% efficient and then 50/64 = > 78.125% at the subnet level but your total efficiency is only > 500/1024 = 48.8%. I'm aware of how traditional addressing works. I'll reiterate a previous comment I made: >> However, the IPv4 free pool is nearing exhaustion so >> it is unlikely that the processes and procedures used when IPv4 was >> plentiful will continue to be appropriate. The transition from being able to obtain IPv4 from the free pool to being unable to obtain IPv4 from the free pool WILL be painful. There is no way around this. Really. The point of the "Soft Landing" policy is to encourage folks to deal with the situation sooner rather than waiting until they hit a wall. Alain appears to be distressed that the "Soft Landing" policy will require increased efficiency in order to obtain additional IPv4 address space from the RIRs. The alternative to "Soft Landing" is one day in the relatively near future, Alain will _NOT_ be able to obtain additional IPv4 addresses from the RIRs. Period. > My ideal scenario is one where nothing changes, except for a > possible gradual increase in the yearly number of address use, so > we don't have to keep coming up with new predictions that people > are going to ignore if they don't like them. Predictability is key. And how would you propose to enforce predictability in address space consumption? How does putting the car on cruise control and closing your eyes remove the wall that is in front of your car? Rgds, -drc From iljitsch at muada.com Wed May 23 04:07:57 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 23 May 2007 10:07:57 +0200 Subject: [ppml] Arguments against Policy Proposal: IPv4 Soft Landing In-Reply-To: <22FC72C5-2EF1-4B91-AE5A-B4269BE4CC81@virtualized.org> References: <027B687B-50EF-4D02-9EE5-677BEFA1C7E0@virtualized.org> <7DA91B2A-B88B-4AC3-B7EF-502ADC1366F9@muada.com> <22FC72C5-2EF1-4B91-AE5A-B4269BE4CC81@virtualized.org> Message-ID: <559EF8B0-E68E-4406-A9BC-87A68905F0B0@muada.com> On 23-mei-2007, at 9:10, David Conrad wrote: >> The way I see it, the only people who can successfully request >> really big blocks of address space, are people who already hold >> really big blocks of address space, > You believe this because...? Because someone requesting 4 million addresses or something like that out of the blue would seem way too fishy. You need a lot of infrastructure to be able to deploy those addresses, and by now, everyone with a lot of infrastructe is already doing IP so they'll already have significant amounts of address space. If it's a new business, presumably, they'd need some time to be in the position to deploy all those addresses so they wouldn't need the really large block immediately, but they could start with a much smaller block. >>> However, the IPv4 free pool is nearing exhaustion so >>> it is unlikely that the processes and procedures used when IPv4 was >>> plentiful will continue to be appropriate. We've been "nearing exhaustion" for a decade now. I don't think we can do much better than what we have now before we start throwing away babies in the bath water. > The transition from being able to obtain IPv4 from the free pool to > being unable to obtain IPv4 from the free pool WILL be painful. > There is no way around this. Really. This is the cental issue. Since we can't avoid the eventual pain when the point comes that the RIRs have to say "sorry, we don't have enough free addresses to honor your request", the question is: how do we minimize the pain BEFORE that happens? My answer: by keeping the IPv4 policies the way they are now. The policies aren't always entirely pain-free, but the industry as a whole can deal with them without too much trouble. >> Predictability is key. > And how would you propose to enforce predictability in address > space consumption? How does putting the car on cruise control and > closing your eyes remove the wall that is in front of your car? A better analogy would be that you're almost out of gas. My position is that you should keep driving until you're flat out. Your position is that you should reduce speed so that people will see there is a problem and take the bus instead. From jcurran at istaff.org Wed May 23 08:18:09 2007 From: jcurran at istaff.org (John Curran) Date: Wed, 23 May 2007 08:18:09 -0400 Subject: [ppml] IPv6 Killer App (Re: getting converts to V6) In-Reply-To: <46511682.3050902@Dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405E20326@CL-S-EX-1.stanleyassociates.com> <4650B317.7090607@Dilkie.com> <4650D2EC.5000002@spaghetti.zurich.ibm.com> <46511682.3050902@Dilkie.com> Message-ID: At 11:48 PM -0400 5/20/07, Lee Dilkie wrote: > >And all this fits how, you ask? The original email talked of trying to >get folks converted to IPv6. I pointed out that, contrary to some other >opinions, it's not the ISPs that need converting (though they certainly >do, but they will anyway to follow the money) but rather the industry >(the "internet") needs to create demand to move to IPv6 with some >as-yet-discovered killer IPv6 application that will make the switch a >compelling one for the end users. In general, I try to avoid making public comments due to avoid any possible confusion with my role as an ARIN board member. However, it's probably worth it it in this case, as this is an excellent question that shouldn't go unanswered. The ARIN Board has not considered the specific question above, and hence has no position on it . Speaking personally, from experience running a few Internet service providers, I offer the following thoughts: Right now, it would be very useful for everyone to consider how they can enable their existing services to be reachable via IPv6 in addition to IPv4. This means the web & mail servers for all organizations, and additional applications for many organizations. There is no incentive to do this, and it has a real cost. I will not speculate on the adoption rate of putting existing services onto IPv6 due to 'market pressure' because there is no actual market pressure today and I'm all too well-aware of the uptake rates of initiatives that are purely undertaken as a "public good". We should make lots of efforts at reclamation, reuse of existing assigned space, and use of previously reserved space. These will extend the time for transition, and that is a good thing. However, the current demand curve for IPv4 address space is very impressive, and none of these efforts will prevent the Internet community from entering a period of time where IPv4 addresses go from being readily available in well-understood blocks to being available in smaller units, via more esoteric measures, in the face of ever-increasing need. Any ISP who claims to have an answer to how they'll obtain the IPv4 addresses necessary for their new customer growth in 2011 is either unaware of the situation or they are being exceedingly optimistic. If most organizations in the Internet community work start today to make their own services available via IPv6, then at some point in the near future IPv6 connectivity will resemble today's Internet service. Yes, there will be still be the need for these customers to have access to/from IPv4-only sites, but it's not hard to imagine how to provide these Internet customers use of an IPv6/IPv4 gateway to get to/from "legacy" IPv4-only services. No, it is not a pretty transition. It is, however, one with understandable costs and certainty of being able to deliver Internet services to customers. That's not a claim that can be made by those who intend to provision customers via IPv4 and expect to be able to do so indefinitely. So, the killer app will exist in near future, at least for the ISP community: The killer application for IPv6 will be the ability to explain to those who like certainty (e.g. investors, governments) that your business as an Internet Service Provider still has a viable plan for ongoing operation and growth. /John p.s. Reproduce/distribute as desired, with or w/o attribution. From Lee.Howard at stanleyassociates.com Wed May 23 10:30:46 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 23 May 2007 10:30:46 -0400 Subject: [ppml] clarification of IPv4 and IPv6 fees Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB405EA23BB@CL-S-EX-1.stanleyassociates.com> I said at the April 2007 Members Meeting that I owed the community a clarification of what IPv6 fees would look like when the current waivers expire. I have checked with the Finance Committee, but not the full Board. It is our common understanding that beginning January 1, 2008, when temporary waivers for IPv6 have expired, that subscriber members will pay the greater of their IPv4 or IPv6 fees, not both. That is to say that ISPs will pay for either their IPv4 renewal or their IPv6 renewal, whichever dollar amount is higher. End user organizations who pay a $100 consolidated annual maintenance fee will pay the same annual maintenance. We have also received a number of excellent suggestions for other ways to structure fees. We are collecting data to see how each model would affect ARIN's long term ability to continue providing services, and will be discussing them in the coming months. I hope that is clearer, and I will be working with the ARIN staff on language for the web site that reflects the intent. Your Treasurer, Lee Howard From jlewis at lewis.org Wed May 23 10:49:33 2007 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 23 May 2007 10:49:33 -0400 (EDT) Subject: [ppml] clarification of IPv4 and IPv6 fees In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB405EA23BB@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405EA23BB@CL-S-EX-1.stanleyassociates.com> Message-ID: On Wed, 23 May 2007, Howard, W. Lee wrote: > I said at the April 2007 Members Meeting that I owed the > community a clarification of what IPv6 fees would look like > when the current waivers expire. I have checked with the > Finance Committee, but not the full Board. It is our common > understanding that beginning January 1, 2008, when temporary > waivers for IPv6 have expired, that subscriber members will > pay the greater of their IPv4 or IPv6 fees, not both. Glad to see my suggestion was taken :) But seriously, http://www.arin.net/billing/fee_schedule.html ought to be updated, because from a quick reading of it, it's certainly implied that after the current IPv6 fee waiver ends in 2007, members will be hit with the additional fees of paying annual fees for both their IPv4 and IPv6 space. When I started looking at doing an IPv6 initial request, I stopped when I saw this. I didn't want to have my employer incur an additional $2250 annual ARIN fee for IP space we might not really use for who knows how long. We've got a lot of hardware and software that will need to be upgraded/replaced, and who knows how far off general usability of IPv6 over the internet is? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From spetty at iconnect-corp.com Wed May 23 11:03:28 2007 From: spetty at iconnect-corp.com (Steven E. Petty) Date: Wed, 23 May 2007 11:03:28 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned Message-ID: <428E6440939F654F8BD72C49361E855FB94EE7@host252.iconnect-corp.com> me: 30-40 vpn's to migrate, mostly with large companies that move slowly (Ford, Chrysler, Covisint, etc.) and have very limited flexibility. -----Original Message----- From: bmanning at karoshi.com [mailto:bmanning at karoshi.com] Sent: Tuesday, May 22, 2007 6:23 PM To: Jo Rhett Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-6 - Abandoned On Tue, May 22, 2007 at 02:56:21PM -0700, Jo Rhett wrote: > On Apr 29, 2007, at 10:51 AM, Alex wrote: > > Actually, no, not the only reason, just one reason. The main reason > > I would > > like PI space is so that I can excercise freedom of choice among > > upstream > > ISPs without having to renumber, and so that I will not again be in > > danger > > of losing my livelihood when my upstream goes out of business or is > > bought. > > If you are in danger of losing your livelihood because of a forced > renumber, then you need to determine what about your business creates > that dependancy and fix it. > > Renumbering is fairly trivial. This whole idea that renumbering is > painful and difficult has no basis in reality except for people who > hardcode IP addresses into their applications, and ARIN does not have > to accept ridiculous actions like that. me: I have spent 650,000 on HP Openview to manage my networks and they code the license key to the IP address of the node. ... I'd really rather not have to renumber and buy new licenses. > -- > Jo Rhett > senior geek > > Silicon Valley Colocation > Support Phone: 408-400-0550 > > > > > _______________________________________________ > 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 jeroen at unfix.org Wed May 23 11:16:26 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 23 May 2007 16:16:26 +0100 Subject: [ppml] Using IPv6 (Was: clarification of IPv4 and IPv6 fees) In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB405EA23BB@CL-S-EX-1.stanleyassociates.com> Message-ID: <46545ACA.8090703@spaghetti.zurich.ibm.com> [subject changed so that people won't mix it up with the fees] Jon Lewis wrote: > [...] We've got a lot of hardware and software that will need to be > upgraded/replaced, and who knows how far off general usability of IPv6 > over the internet is? Depends on how your network is connected to the rest of the Internet. According to many people I know and from my own experiences everything is as smooth as a baby, just like IPv4. For that matter, I tend not to notice if something is IPv4 or IPv6, until I hit an ISP who doesn't know how to properly configure things, but that might be in both v4 and v6. When you have one or more proper transit providers everything will be more or less just like IPv4, the only real difference: larger address space, (and of course linklocals, no ARP, RA's instead of DHCP, though you can do DHCPv6 etc etc etc..) When you have an IPv6 operational issue don't hesitate to raise that at: http://lists.cluenet.de/mailman/listinfo/ipv6-ops Also, where possible and of course where one thinks it has a use, sign up to GRH (http://www.sixxs.net/tools/grh/) and provide a BGP feed. This allows you to see what prefixes you are missing, see where routing might be wrong, giving you the ability to ask your transit about it, who most likely also participates, and it gives the rest of the community a little peek into your routing tables, offering the ability to see what might be causing certain problems. Check the above list, you'll see it can be quite valuable to have that kind of system. Of course, if possible and available near you, try to hook up to RIPE's RIS (http://ris.ripe.net) system or even TTM, which are great projects for helping resolve any problems that might occur. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From dlw+arin at tellme.com Wed May 23 11:42:11 2007 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 23 May 2007 08:42:11 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <428E6440939F654F8BD72C49361E855FB94EE7@host252.iconnect-corp.com> References: <428E6440939F654F8BD72C49361E855FB94EE7@host252.iconnect-corp.com> Message-ID: <20070523154211.GK5379@shell01.corp.tellme.com> On Wed, May 23, 2007 at 11:03:28AM -0400, Steven E. Petty wrote: > me: 30-40 vpn's to migrate, mostly with large companies that move slowly (Ford, Chrysler, Covisint, etc.) and have very limited flexibility. I'll second that thought. There's nothing notably dificult about renumbering, but anywhere you have a direct interaction with another organization (and vpns are notorious for this), you're likely to have a longer time line for making the change. When we need to make major vpn changes across our customer base, we assume it will take at least 6-8 months to complete, just to walk all of them through their own internal change processes. Never underestimate the sheer inertia of a Fortune 100 company. -David From kkargel at polartel.com Wed May 23 11:58:23 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 23 May 2007 10:58:23 -0500 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070523154211.GK5379@shell01.corp.tellme.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706F4D@mail> A boatload of mom and pop shops are no easier.. I have quite a few small businesses with zero IT staff, and users who don't know what an IP address is. They have VPN's that franchise or vendor headquarters say they have to have to do business. It can be painful just explaining to them why they need to change their working VPN. They respond with "It works, leave it alone". When we do convince them things need adjusting now we need to pull their corporate offices in to the mix. Again comes a long conversation explaining why the change to something that is working is needed. It ends up being a lot of telephone time, and in the case of the less sophisticated customers a truck roll. So even non-fortune companies can have if not inertia, then hysteresis.. These are customers that give us money. I cannot just say "Things changed and you're broken till you adjust." Kevin :$s/worry/happy/g > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David Williamson > Sent: Wednesday, May 23, 2007 10:42 AM > To: Steven E. Petty > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2007-6 - Abandoned > > On Wed, May 23, 2007 at 11:03:28AM -0400, Steven E. Petty wrote: > > me: 30-40 vpn's to migrate, mostly with large companies > that move slowly (Ford, Chrysler, Covisint, etc.) and have > very limited flexibility. > > I'll second that thought. There's nothing notably dificult > about renumbering, but anywhere you have a direct interaction > with another organization (and vpns are notorious for this), > you're likely to have a longer time line for making the > change. When we need to make major vpn changes across our > customer base, we assume it will take at least 6-8 months to > complete, just to walk all of them through their own internal > change processes. > > Never underestimate the sheer inertia of a Fortune 100 company. > > -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 jrhett at svcolo.com Wed May 23 14:09:31 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 23 May 2007 11:09:31 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <008401c79cce$ccc4bcf0$08067126@basespacenf1s7> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt><005b01c78a87$0edf4600$08067126@basespacenf1s7><7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com><20070522222317.GB28368@vacation.karoshi.com.><12533.1179875669@sa.vix.com> <49D13C39-1A8A-4E90-AC28-F42595975B6F@svcolo.com> <008401c79cce$ccc4bcf0$08067126@basespacenf1s7> Message-ID: <76328947-9E07-4C27-B13E-8B09A7AEFE06@svcolo.com> On May 22, 2007, at 5:10 PM, Alex wrote: > I am boggled by this assertion. Did you really take responsibility for > looking up how to change the IP address on whatever ancient > hardware and > software each customer had colocated with you? Is this painful? I'm sorry, but wanting to avoid an hours worth of work does not justify the cost of upgrades that *EVERY* router with a full table would have to undertake. Cost of an hours worth of time < $200k per big iron system * (number of big iron systems) Seriously! I can't believe that this keeps getting trotted out as "oh my god, the horror". The real horror is the cost associated with upgrades so that there is more CAM/FIB/etc space on the line cards. > Furthermore, did you not have > customers who pushed back on this and were unhappy that you needed > to touch > their machine? We don't touch their machines. And yes, people complained. But the reality is that it only took them a few hours of work to do make the change, and thus it blows over. > I congratulate you on your customer service. All I can say is, your > experience does not match mine. When I had to renumber, it was > painful, and > customers were unhappy, and a couple of them did leave shortly > thereafter - > not of course admitting that the renumbering was the cause. It wouldn't have been the only cause. Not trying to be rude or pass judgement, but a customer won't leave you for only that reason. > The real question, though, is: are you willing to do it all again > every few > years when your upstream from whom you get PA space is bought, Actually we did this to get rid of 12x blocks of PA space and consolidate into PI space. However, we are a fairly large provider and we burn through space fairly quickly, even with *very* strict allocation policies. > The real problem with lack of PI space is it > removes freedom of choice from the little guy, which places > negotiating > power in the hands of the big upstream providers. Only if you are willing to hardcode your IP addresses into your applications. I used to run "a little guy". We could and did and would renumber within an hour. We designed it that way so that any given provider's space could be dropped from use as needed. Net cost of designing it that way... hard to guess. It was a fairly trivial problem to solve. Maybe 8 hours of work? Thrown against all the work-years put into the colocation design, the service design, the redundancy setup it wasn't even noticed. FYI: for "little guy" I'm talking about an end customer. If you are a provider who suballocates space then you would be multihomed and qualify for a large block and this conversation is irrelevant. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Wed May 23 14:14:45 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 23 May 2007 11:14:45 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <428E6440939F654F8BD72C49361E855FB94EE7@host252.iconnect-corp.com> References: <428E6440939F654F8BD72C49361E855FB94EE7@host252.iconnect-corp.com> Message-ID: <1E493FEA-564C-4105-9652-8E19388D7EE1@svcolo.com> On May 23, 2007, at 8:03 AM, Steven E. Petty wrote: > me: 30-40 vpn's to migrate, mostly with large companies that > move slowly (Ford, Chrysler, Covisint, etc.) and have very limited > flexibility. So while you are doing the hard work of renumbering, I assume you'll also document the process and confirm with all parties how you'll change endpoints in the future, yeah? As I said in a private conversation with Owen Delong, I don't believe that ARIN policy should be designed to allow companies to deliberately drag their feet. Reasonable time to change, absolutely. Even double reasonable time. But I don't think that every provider with big iron should pay millions of dollars in upgrades to allow companies to be inflexible on such a trivial topic. Given that ARIN currently gives longer than either the US Post Office or the telcos do for changes to zip codes and area codes, I struggle to find reason with these arguments. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Wed May 23 14:16:39 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 23 May 2007 11:16:39 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070523154211.GK5379@shell01.corp.tellme.com> References: <428E6440939F654F8BD72C49361E855FB94EE7@host252.iconnect-corp.com> <20070523154211.GK5379@shell01.corp.tellme.com> Message-ID: <2D77E67B-6D32-449F-8A76-D7BADDCB7560@svcolo.com> On May 23, 2007, at 8:42 AM, David Williamson wrote: > I'll second that thought. There's nothing notably dificult about > renumbering, but anywhere you have a direct interaction with another > organization (and vpns are notorious for this), you're likely to > have a > longer time line for making the change. When we need to make major > vpn > changes across our customer base, we assume it will take at least 6-8 > months to complete, just to walk all of them through their own > internal > change processes. > > Never underestimate the sheer inertia of a Fortune 100 company. Ah. So what we have here is a business risk that needs to be properly evaluated and dealt with in the contracts and service provisions with that company. I don't believe that I should be required to put $2-5 million of upgrades into my gear because these needs weren't properly addressed in a company's processes. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Wed May 23 14:18:29 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 23 May 2007 11:18:29 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066706F4D@mail> References: <70DE64CEFD6E9A4EB7FAF3A063141066706F4D@mail> Message-ID: <71D08DC8-F785-420B-8AA0-D0684F7B1390@svcolo.com> On May 23, 2007, at 8:58 AM, Kevin Kargel wrote: > So even non-fortune companies can have if not inertia, then > hysteresis.. > > These are customers that give us money. I cannot just say "Things > changed and you're broken till you adjust." Okay, this is your business risk. What have you done to solve it? Why should I have to replace *every* linecard in all of our big iron just to allow you to not have to face this problem? Explain in detail, please. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From james at towardex.com Wed May 23 14:29:29 2007 From: james at towardex.com (James Jun) Date: Wed, 23 May 2007 14:29:29 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <71D08DC8-F785-420B-8AA0-D0684F7B1390@svcolo.com> References: <70DE64CEFD6E9A4EB7FAF3A063141066706F4D@mail> <71D08DC8-F785-420B-8AA0-D0684F7B1390@svcolo.com> Message-ID: <006401c79d68$5b636a30$1efc5dd8@HCMC.local> > > Okay, this is your business risk. What have you done to solve it? > > Why should I have to replace *every* linecard in all of our big iron > just to allow you to not have to face this problem? Explain in > detail, please. You don't have to. You can filter his routes out and your bigiron would be happy. -- Regards, James Jun Managing Director TowardEX Technologies, Inc. Phone: +1 617-459-4051 x179 Mobile: +1 978-394-2867 Fax: +1 432-225-3784 Email: james at towardex.com From alex at basespace.net Wed May 23 17:48:41 2007 From: alex at basespace.net (Alex) Date: Wed, 23 May 2007 17:48:41 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt><005b01c78a87$0edf4600$08067126@basespacenf1s7><7BB3CB0E-871E-4F84-A682-0558C1E5B738@svcolo.com><20070522222317.GB28368@vacation.karoshi.com.><12533.1179875669@sa.vix.com> <49D13C39-1A8A-4E90-AC28-F42595975B6F@svcolo.com> <008401c79cce$ccc4bcf0$08067126@basespacenf1s7> <76328947-9E07-4C27-B13E-8B09A7AEFE06@svcolo.com> Message-ID: <002e01c79d84$20fcf0c0$08067126@basespacenf1s7> > FYI: for "little guy" I'm talking about an end customer. If you are > a provider who suballocates space then you would be multihomed and > qualify for a large block and this conversation is irrelevant. > Actually, I am multihomed, but I do NOT qualify for a large block because I am too small - exactly the situation that policy proposal 2007-6 was created to address. I have PA space because that is all I can get under current policies. Nevertheless I have about 30 downstream customers, mostly folks who colocate a single server. Thank you for your response, - Alex Aminoff BaseSpace.net From jrhett at svcolo.com Wed May 23 17:51:01 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 23 May 2007 14:51:01 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <006401c79d68$5b636a30$1efc5dd8@HCMC.local> References: <70DE64CEFD6E9A4EB7FAF3A063141066706F4D@mail> <71D08DC8-F785-420B-8AA0-D0684F7B1390@svcolo.com> <006401c79d68$5b636a30$1efc5dd8@HCMC.local> Message-ID: <873EA03B-7DEB-4B0D-9984-E4FE4CFBE98C@svcolo.com> On May 23, 2007, at 11:29 AM, James Jun wrote: >> Okay, this is your business risk. What have you done to solve it? >> >> Why should I have to replace *every* linecard in all of our big iron >> just to allow you to not have to face this problem? Explain in >> detail, please. > > You don't have to. You can filter his routes out and your bigiron > would be > happy. And now he can't reach my customers and vice versa. This is not helpful. Let's focus on real solutions. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From marla.azinger at frontiercorp.com Wed May 23 18:51:22 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 23 May 2007 18:51:22 -0400 Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 Message-ID: <454810F09B5AA04E9D78D13A5C39028A023EF9AA@nyrofcs2ke2k01.corp.pvt> Managed ULA would be a better answer than using global space. Only ARIN has this type of policy as a work around. I think there are alot of people out there who feel a good ULA Global policy carried out at the RIR level would be better than wasting global address space. My two cents Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Kevin Loch Sent: Monday, May 21, 2007 9:10 AM Cc: ppml at arin.net Subject: Re: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 Anthony A. Crumb wrote: > > I think it is great that we are spreading the word, and I am glad that > ARIN has made this announcement. Now we need to put the issue > ULA-central or ULA-local to bed. I am sure that I will not be able to > justify more than one /48 globally routable prefix for my US internet > presence. Because the last 64 bits of the address are required for > interface identifiers that only leaves me with 16 bits with which to > create a hierarchical enterprise address allocation model. 16 bit of > subnetting space is not enough to create subnet allocation model for a > large enterprise. The current PI policy does allow for variable sized assignments based upon need for more than 65536 subnets. There have been two such assignments made so far. I'm sure if you submit an application that reasonably justifies your request you can get the subnets you need, as that was the intent of the policy. We do need to make that policy more specific as to what "justify" means so if you have any suggestions we would love to hear them. - Kevin _______________________________________________ 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 Wed May 23 19:38:20 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 23 May 2007 18:38:20 -0500 Subject: [ppml] ARIN Board Advises Internet Community on Migrationto IPv6 References: <454810F09B5AA04E9D78D13A5C39028A023EF9AA@nyrofcs2ke2k01.corp.pvt> Message-ID: <011101c79d95$600b9c10$b1b0df0a@atlanta.polycom.com> Thus spake "Azinger, Marla" > Managed ULA would be a better answer than using global space. > Only ARIN has this type of policy as a work around. I think there > are alot of people out there who feel a good ULA Global policy > carried out at the RIR level would be better than wasting global > address space. First, either flavor of ULA would only give him a /48 and he's indicated that's not sufficient; there's official answer to that situation is getting multiple prefixes, which dramatically increases either the odds of collisions (Local) or the cost (Central). Second, IMHO there is no shortage of v6 space that merits denying requests from people who can justify use in return for forcing them to renumber if/when they connect to the public Internet. If they never end up advertising the space, there is no argument that they're consuming routing slots, which is the only reason _not_ to give a PI space to everyone who asks. There's no shortage of /48s. The _only_ situation I can see where ULA Central has an edge over PIv6 is when an org is small enough they don't meet the bar for a global address yet has enough private peers that they have a non-trivial chance of collision. I believe that such circumstances are rare enough that approving ULA Central is not justified. My two cents as well, 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 Wed May 23 21:53:56 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 23 May 2007 21:53:56 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070523154211.GK5379@shell01.corp.tellme.com> References: <428E6440939F654F8BD72C49361E855FB94EE7@host252.iconnect-corp.com> <20070523154211.GK5379@shell01.corp.tellme.com> Message-ID: <20070524015356.GB77370@ussenterprise.ufp.org> In a message written on Wed, May 23, 2007 at 08:42:11AM -0700, David Williamson wrote: > I'll second that thought. There's nothing notably dificult about > renumbering, but anywhere you have a direct interaction with another > organization (and vpns are notorious for this), you're likely to have a > longer time line for making the change. When we need to make major vpn > changes across our customer base, we assume it will take at least 6-8 > months to complete, just to walk all of them through their own internal > change processes. I used to think this was a really gross solution, but as the years go by I see the wisdom. I've been at several companies where each VPN is done with a /30 between the companies, and a NAT on BOTH sides. The /30 needs only be known as a directly connected to the boxes on each side, and can overlap with any of your internal addresses. You NAT all communication to whatever IP you want on the inside of your respective routers. This obviously requires something that works through NAT, but that's a lot of things these days. It offends almost every bone in my body, but it does work. However, I think the point several other posters made is important. We renumber businesses we purchase all the time. You need to have plans to renumber others and renumber yourself. You need to invest in good DHCP tools, good DNS tools, and understand how to manage things like static IP'ed printers. This is all true even if you're on 1918 space. Anything else is a business continuity risk. -- 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 dean at av8.com Thu May 24 00:22:54 2007 From: dean at av8.com (Dean Anderson) Date: Thu, 24 May 2007 00:22:54 -0400 (EDT) Subject: [ppml] getting converts to V6 In-Reply-To: Message-ID: On Sun, 20 May 2007, David Conrad wrote: > > > Someone is making a boatload of money here. Or wasting a boatload. > > ARIN's budget is published at http://www.arin.net/about_us/corp_docs/ > budget.html. Please point to where someone is making or wasting a > boatload of money. Ok, I'll bite on this. I have an insatiable curiousity about such things. ;-) This may be the wrong forum, though. The 2005 financials state that ARIN has about 19 million in investments. But reports only $366,597 in interest and dividends. This is less than 2%. That seems to be a pretty poor return on over $19mil. The investing cash flows suggest some turnover, but its hard for me to tell what's happening. Are there unrealized capital gains in this value? What is the realistic total worth of the investments? Who is managing these investments? ARIN had about 9 million in revenue, and about 7 million in operations expenses, so ARIN made about 2million in 2005 (before investments) and made about 1.3million in 2004. Good work folks! So, yes. ARIN is making a small boatload of money, has been for a while, and ARIN has been saving it up. But it is unclear if ARIN has been investing wisely. Perhaps some more transparancy on the investments would be helpful. Thanks, --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dlw+arin at tellme.com Thu May 24 01:14:42 2007 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 23 May 2007 22:14:42 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070524015356.GB77370@ussenterprise.ufp.org> References: <428E6440939F654F8BD72C49361E855FB94EE7@host252.iconnect-corp.com> <20070523154211.GK5379@shell01.corp.tellme.com> <20070524015356.GB77370@ussenterprise.ufp.org> Message-ID: <20070524051442.GA5379@shell01.corp.tellme.com> On Wed, May 23, 2007 at 09:53:56PM -0400, Leo Bicknell wrote: > I've been at several companies where each VPN is done with a /30 > between the companies, and a NAT on BOTH sides. You can do that, perhaps, unless you can't. A few protocols just won't work (SIP is a notable example), and you need someone with a clue about how to setup a NAT on each end. That's not a given. We have one partner that put their senior network architect on the phone with us. When we inquired about using BGP for dynamic routing, he said, and I'm not making this up, "what's bgp?" That's another Fortune 100 company. For obvious reasons, I won't identify which one. > However, I think the point several other posters made is important. We > renumber businesses we purchase all the time. You need to have plans to > renumber others and renumber yourself. You need to invest in good DHCP > tools, good DNS tools, and understand how to manage things like static > IP'ed printers. This is all true even if you're on 1918 space. > Anything else is a business continuity risk. That's absolutely true. We can renumber *most* of our space very quickly. Unfortunately, the rest takes months, in the best case scenario. And we can't exactly dictate aggresive contract terms to much larger companies that are paying a premium to use our services. I really think people who think renumbering is easy don't work for ASP-like companies. There's a few specific challenges that make it a thorny problem. A large amount of embedded addresses in vpns and customer-controlled ACLs are just a nightmare, especially when NAT isn't an option. -David From jcurran at istaff.org Thu May 24 06:29:39 2007 From: jcurran at istaff.org (John Curran) Date: Thu, 24 May 2007 06:29:39 -0400 Subject: [ppml] ARIN investment returns In-Reply-To: References: Message-ID: At 12:22 AM -0400 5/24/07, Dean Anderson wrote: >The 2005 financials state that ARIN has about 19 million in investments. >But reports only $366,597 in interest and dividends. This is less than >2%. That seems to be a pretty poor return on over $19mil. The >investing cash flows suggest some turnover, but its hard for me to tell >what's happening. Are there unrealized capital gains in this value? >What is the realistic total worth of the investments? Who is managing >these investments? The actual gain from investments is the interest ($366,597) plus gains-realized and unrealized ($506,133), for a total of $872,730. This is earned against investment assets which were $15,371,039 at the start of the period, for a yield of approximately 5.6%. These numbers are in the published report, but I admit it can be challenging to read it that way. FYI - The investments in that period where managed by Legg Mason/Citigroup. >ARIN had about 9 million in revenue, and about 7 million in operations >expenses, so ARIN made about 2million in 2005 (before investments) and >made about 1.3million in 2004. Good work folks! ARIN has also reduced fees 3 or 4 times since its inception, although the members have historically asked us to focus on more services and more outreach rather than fee reductions. >So, yes. ARIN is making a small boatload of money, has been for a while, >and ARIN has been saving it up. But it is unclear if ARIN has been >investing wisely. Perhaps some more transparancy on the investments >would be helpful. I hope the above helped clarify the 2005 yield; as the one who gets to sign the annual report each year, I'm more than willing to answer any questions you have (although I also reserve the right to hand off any particularly complex queries to our Treasurer, who presents our results at each member meeting and heads the board finance committee.) /John John Curran Chairman, ARIN Board of Trustees p.s. With respect to the right forum for this, arin-discuss at arin.net is normally where this topic would be handled. From RMaruottolo at bear.com Thu May 24 08:47:11 2007 From: RMaruottolo at bear.com (Maruottolo, Richard) Date: Thu, 24 May 2007 08:47:11 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned Message-ID: <5777864ED563124EA7898F96C407BFF305178113@whexchmb01.bsna.bsroot.bear.com> ON Thursday, May 24, 2007 1:15 AM David Williamson wrote in response to Leo Bicknell's point: > That's absolutely true. We can renumber *most* of our space very quickly. > Unfortunately, the rest takes months, in the best case scenario. > And we can't exactly dictate aggressive contract terms to much larger companies > that are paying a premium to use our services. Having had to IP renumber, here are some of the reasons for the *rest* taking months: *Firewall rules that are bound via IP addresses NOT DNS *Application systems such as load balancers are mapped to IP addresses NOT DNS. *Legacy systems that are not DNS such as mainframe *Need to maintain 99.999% application availability. No room for error. It can be done but there are in many cases significant hurdles and potential risks to the firm renumbering that need to be handled. I have lost many hours of sleep on weekends doing such migrations for large firms where the impact of a mistake or downtime in financial lost is enormous. Saying the *rest* can take months is an understatement in many cases. -Rick -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of David Williamson Sent: Thursday, May 24, 2007 1:15 AM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-6 - Abandoned On Wed, May 23, 2007 at 09:53:56PM -0400, Leo Bicknell wrote: > I've been at several companies where each VPN is done with a /30 > between the companies, and a NAT on BOTH sides. You can do that, perhaps, unless you can't. A few protocols just won't work (SIP is a notable example), and you need someone with a clue about how to setup a NAT on each end. That's not a given. We have one partner that put their senior network architect on the phone with us. When we inquired about using BGP for dynamic routing, he said, and I'm not making this up, "what's bgp?" That's another Fortune 100 company. For obvious reasons, I won't identify which one. > However, I think the point several other posters made is important. > We renumber businesses we purchase all the time. You need to have > plans to renumber others and renumber yourself. You need to invest in > good DHCP tools, good DNS tools, and understand how to manage things > like static IP'ed printers. This is all true even if you're on 1918 space. > Anything else is a business continuity risk. That's absolutely true. We can renumber *most* of our space very quickly. Unfortunately, the rest takes months, in the best case scenario. And we can't exactly dictate aggresive contract terms to much larger companies that are paying a premium to use our services. I really think people who think renumbering is easy don't work for ASP-like companies. There's a few specific challenges that make it a thorny problem. A large amount of embedded addresses in vpns and customer-controlled ACLs are just a nightmare, especially when NAT isn't an option. -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 *********************************************************************** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *********************************************************************** From bicknell at ufp.org Thu May 24 22:11:54 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 24 May 2007 22:11:54 -0400 Subject: [ppml] Slashdot and Ars Technica Commentary Message-ID: <20070525021154.GA43632@ussenterprise.ufp.org> Ars Technica has a commentary on the IPv6 issues and the board's recent press release... http://arstechnica.com/news.ars/post/20070521-arin-its-time-to-migrate-to-ipv6.html And now the masses are commenting on Slashdot... http://it.slashdot.org/article.pl?sid=07/05/24/2225218 Just an FYI to see what the general public thinks of the situation. -- 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 stephen at sprunk.org Sun May 27 16:51:41 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 27 May 2007 15:51:41 -0500 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewallsvs NAT in arstechnica (seen on slashdot) References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> Message-ID: <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> Thus spake "Iljitsch van Beijnum" > On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: >> And the only way to control ULA-central is to have it within the >> RIR system, > > How would that work in practice? Approximately 100% of all > organizations use RFC 1918 space. Obviously one use for > RFC 1918 space goes away with IPv6 (NAT) but I'd say that > the number of internet users requiring some kind of local > addressing will still be 10, 20, 30 or more percent. The RIR > membership is measured in thousands. All correct. > So tens of thousands or even hundreds of thousands of > organizations that may want ULA-c space have no relationship > with an RIR. They may not even have a relationship with an ISP... > > So how are the RIRs supposed to manage their relationship > with 10 or 100 times as many people as they have relationships > with now? You have the flawed assumption that everyone who uses RFC1918 space today will want/need ULA-C in the future. The vast majority of folks will be fine with ULA-L (or PA) space, and the target market for ULA-C is identical to the target market for PIv6. It will be the same number of orgs regardless of which type of space they request, so the debate comes down to why we want to put orgs on ULA-C space instead of just giving them PI space. If they're truly going to use it privately, they won't consume routing slots in the DFZ, and if they aren't they'll be using PIv6 anyways and won't have a need for ULA-C. I object to making orgs second-class IPv6 citizens under the guise of "private" addresses, and there is significant risk that ULA-C will end up not being "private" because there will be a set of ISPs that agree to route the space for a fee. If that set grows to critical mass, ULA-C will be no different than PIv6 anyways. 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 iljitsch at muada.com Sun May 27 19:42:21 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 28 May 2007 01:42:21 +0200 Subject: [ppml] Slashdot and Ars Technica Commentary In-Reply-To: <20070525021154.GA43632@ussenterprise.ufp.org> References: <20070525021154.GA43632@ussenterprise.ufp.org> Message-ID: <2FDC5359-B3EF-49A5-AD4F-76BEFB3AD3B3@muada.com> On 25-mei-2007, at 4:11, Leo Bicknell wrote: > Ars Technica has a commentary on the IPv6 issues and the board's > recent > press release... > http://arstechnica.com/news.ars/post/20070521-arin-its-time-to- > migrate-to-ipv6.html How is this commentary? If you look at http://news.google.com/news?q=arin+ipv6 you'll see that the 2010 date is widely reported without many caveats. > And now the masses are commenting on Slashdot... > http://it.slashdot.org/article.pl?sid=07/05/24/2225218 > Just an FYI to see what the general public thinks of the situation. /. isn't exactly representative of the general public... And Slashdot IPv6 discussions pretty much go along these lines: "Use NAT, n00b. All 1337 of my Linux boxes share a single IP and it's safer, too!" "NAT is not a firewall." "NAT sucks." "You suck." It is interesting to note that the discussion always comes back to the legacy class A issue. I'm thinking that IF we want (some of) that reclaimed, the powers that be must set this in motion sooner rather than later to allow for the lawyers to do their thing before the space is needed. And if not, some explaining why this isn't going to happen would be good. From iljitsch at muada.com Mon May 28 08:17:54 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 28 May 2007 14:17:54 +0200 Subject: [ppml] Slashdot and Ars Technica Commentary In-Reply-To: <465A2D08.6040809@bogus.com> References: <20070525021154.GA43632@ussenterprise.ufp.org> <2FDC5359-B3EF-49A5-AD4F-76BEFB3AD3B3@muada.com> <465A2D08.6040809@bogus.com> Message-ID: On 28-mei-2007, at 3:14, Joel Jaeggli wrote: >> It is interesting to note that the discussion always comes back to >> the legacy class A issue. I'm thinking that IF we want (some of) that >> reclaimed, the powers that be must set this in motion sooner rather >> than later > Seizing resources in the name of public interest has such excellent > historical precedents... I can't attest to the quality, but there are precedents. > It seems likely that legacy address holders might see themselves as > materially harmed by attempts to do so and seek redress. As those > blocks > were not assigned under modern registry service agreements I'm not > sure > that all the possible outcomes of such an exercise are very pretty. That very much depends on the way the reclamation is going to work. The simplest would be "30 days after the passing of this policy all legacy class A space is returned to IANA" and I'm pretty sure this isn't going to work for a variety of reasons. Another option would be that the holders need to sign the current agreement and start paying the ARIN fee associated with the amount of address space involved (although the current $18000/yr fee is probably not enough to overcome inertia). Separately, the RIRs could pass a policy that prohibits the trading in (this type of) address space and that this will be "enforced" by means of the address space certificate system that is being created. With the prospect of making money off of the addresses gone, the organizations involved don't have a reason to hold on to the space if they're really not using it. And it's likely that it's possible to reclaim parts of class A blocks in cases where there is some use. Personally, I don't care all that much: the faster we run out of IPv4, the faster we'll all be on IPv6, and the faster some of the current legacy issues are out of the way. But the point is, that IF we want to do this, it has to happen soon, or it's another missed opportunity, like reclaiming class E space. If we're going to need that space in three years, it's now too late because hundreds of millions of hosts out there have class E hardcoded as invalid and within such a short time, we can't update all of those hosts. From iljitsch at muada.com Mon May 28 08:30:30 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 28 May 2007 14:30:30 +0200 Subject: [ppml] Those pesky ULAs again In-Reply-To: <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> Message-ID: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> On 27-mei-2007, at 22:51, Stephen Sprunk wrote: > Thus spake "Iljitsch van Beijnum" >> On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: >>> And the only way to control ULA-central is to have it within the >>> RIR system, >> >> How would that work in practice? Approximately 100% of all >> organizations use RFC 1918 space. Obviously one use for >> RFC 1918 space goes away with IPv6 (NAT) but I'd say that >> the number of internet users requiring some kind of local >> addressing will still be 10, 20, 30 or more percent. The RIR >> membership is measured in thousands. > > All correct. > >> So tens of thousands or even hundreds of thousands of >> organizations that may want ULA-c space have no relationship >> with an RIR. They may not even have a relationship with an ISP... >> So how are the RIRs supposed to manage their relationship >> with 10 or 100 times as many people as they have relationships >> with now? > You have the flawed assumption that everyone who uses RFC1918 space > today will want/need ULA-C in the future. No, what I said was: >> Approximately 100% of all >> organizations use RFC 1918 space. Obviously one use for >> RFC 1918 space goes away with IPv6 (NAT) but I'd say that >> the number of internet users requiring some kind of local >> addressing will still be 10, 20, 30 or more percent. > The vast majority of folks will be fine with ULA-L Most people aren't very good with statistics, knowing for sure you have unique space is better than having just a 99.9999% probability that it's unique. > (or PA) space PA or PI is irrelevant to this discussion, people who need ULA may not even connect to the internet, and if they do, they need this space in ADDITION to routable address space, regardless of the type. > and the target market for ULA-C is identical to the target market > for PIv6. Nonsense. > so the debate comes down to why we want to put orgs on ULA-C space > instead of just giving them PI space. No-brainer: ULA-C space doesn't use up routing table slots. > If they're truly going to use it privately, they won't consume > routing slots in the DFZ, and if they aren't they'll be using PIv6 > anyways and won't have a need for ULA-C. You are being ridiculous. There is no connection between ULA-C and PI. Everyone can get ULA, not everyone can get PI. And ULA is even more important for people who have PA because that way they can have their internal infrastructure on stable addresses even when their routable address space is renumbered. Also, with IPv4, it's very common to use RFC 1918 space for internal infrastructure that must not be reachable from the internet. It's much more convenient to use unroutable address space for this rather than routable address space that is filtered. > there is significant risk that ULA-C will end up not being > "private" because there will be a set of ISPs that agree to route > the space for a fee. If that set grows to critical mass, ULA-C > will be no different than PIv6 anyways. I don't see the problem. We agree that routing ULA space is a bad idea. However, if someone is prepared to give me enough money to change my mind, how can that possibly be a problem? Or do you want to protect yourself from your own greed? From stephen at sprunk.org Mon May 28 22:42:46 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 28 May 2007 21:42:46 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> Message-ID: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> Thus spake "Roger J?rgensen" > On man, mai 28, 2007 14:30, Iljitsch van Beijnum wrote: >> On 27-mei-2007, at 22:51, Stephen Sprunk wrote: >>> The vast majority of folks will be fine with ULA-L >> >> Most people aren't very good with statistics, knowing for sure >> you have unique space is better than having just a 99.9999% >> probability that it's unique. > > not really, I work a place where we just can?t have any more > collision of address space, we have a few options and ULA- > central is the best. > > 1.) get ula-central and know for sure we won?t get into this > issue ever again. Unless the central administrator(s) screw up. The odds of that are non-zero, you know; in fact, as long as there's humans involved it's safe to say the odds are higher than a ULA-L collision. > 2.) administrate our own local version of ULA-central for > the organization we co-operate with Which is basically ULA-L, except that when someone new wants to join your private club, you'll need to spend a few seconds making sure they don't collide, and if they do (which is statistically unlikely, unless your club is on the scale of the public Internet) they'll need to renumber before they can join. > 3.) get RIR-space with all the add on administration and > documentation... The documentation is minimal unless you need a block larger than the minimum size, and the administration would be the same either way. > For me, only option 1.) is a real option, the other two are just > work-around since we don?t need global routing of the address > space in question. No, you've decided #1 is what you want, so you're downplaying its problems and potential harm to the community and criticizing all other options. >>> (or PA) space >> >> PA or PI is irrelevant to this discussion, people who need ULA >> may not even connect to the internet, and if they do, they need >> this space in ADDITION to routable address space, regardless >> of the type. > > this go for the type of organization I work for. We have our own > /32 already and it suite our need for public address space just > fine given the 3 options above. So why not carve out a /48, block it at your firewall to the public network, and get "local" addresses for free instead of paying for ULA-C? > ULA-central will satisfy a need for non-routable address space > that some bigger organization have. ULA-local are just a no go > even with a 99,99999% chance of no collision at all. Or to put it > in another context, renumbering or any change, experimentation > or downtime of the infrastructure are just not an option when > we?re talking about medicial/health related equipment. If you're in the medical field and your equipment can't withstand a few seconds of outage here and there (six nines = 31sec/yr downtime) without killing someone, you're going to have a lot of dead people on your hands. You and/or your vendors have failed. Networks have outages, period. In a typical network, most of them will be hardware-, circuit-, or design-related. I participated in a project for $BIG_TELCO and it took them several years of effort just to get from three nines to five nines consistently, and they never hit six nines. Nearly all of the remaining issues, when we were done, were due to humans making typos. If you think you're going to get to six (or more) nines of reliability, you're delusional in thinking that you're better at this than people literally throwing billions of dollars and thousands of engineers at the problem. Besides, renumbering should not cause any outages (at least more than what you normally see) unless your staff is incompetent. It's a lot of work, but it shouldn't cause an outage, much less death. >>> so the debate comes down to why we want to put orgs on >>> ULA-C space instead of just giving them PI space. >> >> No-brainer: ULA-C space doesn't use up routing table slots. > > see above, PI or PA have nothing todo in the discussion of > ULA-C or not. Yes, it does. If an org needs unique address space that will never appear in the DFZ, how does ULA-C meet their needs any better than PI? What is the purpose in creating yet another thing that needs to be registered when we already have two alternatives that fit every need I've seen proposed so far? > Site-local, the one that got deprecated would have suited OUR > (where I work) just fine but it isn?t there so we need a > replacement and ULA-C is what we would need. If SLAs would have worked for you, then you have no fundamental need for unique addresses and ULA-Ls are overkill, much less ULA-C. >>> If they're truly going to use it privately, they won't consume >>> routing slots in the DFZ, and if they aren't they'll be using PIv6 >>> anyways and won't have a need for ULA-C. >> >> You are being ridiculous. There is no connection between >> ULA-C and PI. Everyone can get ULA, not everyone can get PI. Anyone who is large enough to care about the extreme unlikelihood of collisions with ULA-L will be able to get PI, at least in ARIN's region. The bar is incredibly low; just about the only folks who don't qualify are people running home networks. And, for that matter, people can get a single PI block larger than /48, whereas someone who needs more than a /48 in ULA-C space would need multiple distinct blocks, presumably multiplying the fees to more than what PI costs. If your argument is that ULA-C will be cheaper, that is perhaps an argument that PI fees are too high -- not that anyone has stated if or how much cheaper ULA-C would be if it did pass. I have a hard time seeing anyone who has a legitimate need for ULA-C _or_ PI space whining about $100/yr. If they can't afford that, they can't afford anyone knowledgeable enough to care about the problems with ULA-L (or PA) space. 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 randy at psg.com Mon May 28 23:44:57 2007 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2007 17:44:57 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> Message-ID: <465BA1B9.1060003@psg.com> ok, i give. if ula address space is assigned/managed by registries, how is it actually different from pi space? if ipv6 space is effectively infinite (and we once thought ipv4 space was), then what is the use of ula address space? why not just assign vanilla ipv6 space? i am very confused by all the smoke and am trying to find the core of this stuff. randy From randy at psg.com Tue May 29 04:26:19 2007 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2007 22:26:19 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> Message-ID: <465BE3AB.8040305@psg.com> >> ok, i give. if ula address space is assigned/managed by >> registries, how is it actually different from pi space? > Basically ULA space has the same 'routability' as RFC1918 space which is a benefit because ...? rfc 1918 space is a hack to deal with an address space shortage. we are told ipv6 space is effectively infinite. hence we do not need rfc 1918 style space. > with the added benefit of less (or in case of ULA central: no) > possibility for conflicting addresses when merging/connecting > separate networks. because, in statistical hope, it will not overlap. i.e. it does not even conserve space a la 1918. so, again, what's the benefit? > PI space is expected to be routed globally (if the user of the space > wants to). as has been amply demonstrated, 1918 space leaks time and again. so this ula stuff will leak time and again. >> if ipv6 space is effectively infinite (and we once thought ipv4 >> space was), then what is the use of ula address space? why not >> just assign vanilla ipv6 space? > At this moment there is no IPv6 PI spa so we do this kinky thing to create a half-assed version of it? pfui! randy From jeroen at unfix.org Tue May 29 05:01:15 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 29 May 2007 10:01:15 +0100 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BE3AB.8040305@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> Message-ID: <465BEBDB.2070200@spaghetti.zurich.ibm.com> (Tony, what where the exact thoughts about the below) Randy Bush wrote: >>> ok, i give. if ula address space is assigned/managed by >>> registries, how is it actually different from pi space? >> Basically ULA space has the same 'routability' as RFC1918 space > > which is a benefit because ...? rfc 1918 space is a hack to deal with > an address space shortage. we are told ipv6 space is effectively > infinite. hence we do not need rfc 1918 style space. The only 'real' benefit I heared up to now was iirc from Tony Hain who mentioned that it might in corporate cases be handy to be able to simply have ULA-Central space as the space that is used internally, and possibly by partner organizations linking in. Thus that you use fc00::/8 on internal + interconnected networks. While using other spaces on the internet (that big public thing). The main advantage is that firewalling becomes easier, as you know that space under fc00::/8 is internal and thus from another company. Splitting routing, doing firewalling etc thus becomes easier as you know what is public and what is not. [..] >> PI space is expected to be routed globally (if the user of the space >> wants to). > > as has been amply demonstrated, 1918 space leaks time and again. so > this ula stuff will leak time and again. ULA space should be !A'ed out by routers per default and have a special switch to enable forwarding for them. Security folks will be quite happy with that too I guess. >>> if ipv6 space is effectively infinite (and we once thought ipv4 >>> space was), then what is the use of ula address space? why not >>> just assign vanilla ipv6 space? IMHO there should not be a distinction between "PI" and "PA" space. Both will be broken up into blocks for "Traffic Engineering" purposes and other such things anyway, as can already be seen in BGP today. It should all simply be 'address space' and the size of the block received from the RIR should be based on the amount of address space they can justify and where possible only 1 such block per organization. The latter is unrealistic too as when an organization breaks up they might want to split that block etc yadiyadi. The only folks who can really stop that from happening is the ISP's themselves. Any organization with enough cash or importance can get any block fairly well routed onto the Internet. Lots of ISP's will protest, but to keep customers they will bend over anyway. If an ISP wants to keep the number of routes they accept low, they can already do this easily by taking all the inet6num's which have been delegated directly from the RIR's and use those to build filters. Filter list will be insanely large, but then you have the minimum you want to accept. Currently the classification between PA/PI sort of helps there as PA is From randy at psg.com Tue May 29 05:09:10 2007 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2007 23:09:10 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BEBDB.2070200@spaghetti.zurich.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <465BEBDB.2070200@spaghetti.zurich.ibm.com> Message-ID: <465BEDB6.3070109@psg.com> > ULA space should be !A'ed out by routers per default and have a > special switch to enable forwarding for them. oh, site-local. i remember that disaster. no wonder the internet-draft was stuffed. as i just told someone else in private email. you are asking that routers hard code the association between routability and address space. and next you only want this at site border routers and not 'internal' routers. this was called site-local, and was soundly rejected as a disaster in the making. use global space and filter your routing announcements and packets. randy From randy at psg.com Tue May 29 05:12:34 2007 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2007 23:12:34 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BEDB6.3070109@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <465BEBDB.2070200@spaghetti.zurich.ibm.com> <465BEDB6.3070109@psg.com> Message-ID: <465BEE82.4000108@psg.com> Randy Bush wrote: >> ULA space should be !A'ed out by routers per default and have a >> special switch to enable forwarding for them. > oh, site-local. i remember that disaster. no wonder the internet-draft > was stuffed. RFC 1925 2(11) ?Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.? randy From iljitsch at muada.com Tue May 29 05:31:14 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 11:31:14 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529091805.GA15655@borg.c-l-i.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> Message-ID: On 29-mei-2007, at 11:18, Shane Kerr wrote: > There are no advantages to ULA (central), as I see it. Which is why I > oppose it. It troubles me that so many people are willing to deprive others of something that those others consider useful just because they themselves don't find that thing useful. Quote from dr. Phil: "If your kid wakes up at night and says 'daddy I'm thirsty can I get some water' you don't say 'I'm not thirsty, you don't need water', you give the kid a glass of water. Everyone has different needs." From iljitsch at muada.com Tue May 29 06:17:21 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 12:17:21 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529100000.GA16216@borg.c-l-i.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> Message-ID: <24EB3E8F-7E8F-43B1-92FC-2EDB8D079128@muada.com> On 29-mei-2007, at 12:00, Shane Kerr wrote: >> It troubles me that so many people are willing to deprive others of >> something that those others consider useful just because they >> themselves don't find that thing useful. > If something is not useful to me, but might be useful to others, I > generally don't oppose it. > But I do not think ULA central is useful to anyone. People have come out and said it's useful to them, so you are putting your judgment ahead of theirs. > Even if ULA central is useful, I don't think it is something the RIRs > need to be involved in. On that, we agree. > If you insist on ULA central, my preferred implementation is a web > page where you click on a button that says "give me a ULA prefix" and > it allocates a random prefix that is not in use, and prints it on the > screen. The only implementation question I'm not sure about is whether > the list of allocated prefixes would be public or not; I lean towards > making it public, although there is a (small) privacy concern. I think > the cost of this implementation is low enough you could find a group > of volunteers to host the system. I think a mechanism similar to IEEE MAC addresses would be good: organizations can buy a block for a price that's large enough to cover the costs of maintaining the IANA registry and also high enough to make sure people aren't going to buy unreasonable quantities ($/eu 1000 - 5000 or so for a block of a million /48s seems about right) and then the block holders can then redistribute the individual ULA prefixes in any way they see fit. Presumably, end-users would buy their prefixes from distributors that have a good system for enforcing uniqueness in place, but this can be traded off against other needs. From rich at nic.umass.edu Tue May 29 06:39:26 2007 From: rich at nic.umass.edu (Rich Emmings) Date: Tue, 29 May 2007 06:39:26 -0400 (EDT) Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> Message-ID: As I mentioned earlier, one of the barriers to getting management buy in on IPv6 is the fact that the standards keep changing, and this is a good example. To use an analogy, the financial boys won't sign off on starting the building until they get a final floor plan. Keep rewriting the spec to try and get it 'perfect' instead of 'good enough' and it'll still be in redesign as the last IPv4 address goes out the door? What problem are we trying to solve here? Is it a valid concern, or are we fighting the last war and blithly ignoring what will be the real problems with IPv6. (Hint, you don't know what it is either. If it's the same problem, it's solved. If it's something you can think of, it's probably being solved. It's novel.) From jordi.palet at consulintel.es Tue May 29 06:55:20 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 12:55:20 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: I don't agree on this. The basic standards for IPv6 are fixed the same as with IPv4, nothing less. We are just having more and new things evolving and this will happen for as much time as new things are required. We always need to improve, solve issues, etc. Same as we keep doing with many other protocols. Actually you could same the same about policies, they keep evolving and changing. It is a natural cycle. Regards, Jordi > De: Rich Emmings > Organizaci?n: University of Massachusetts OIT NSS > Responder a: Rich Emmings > Fecha: Tue, 29 May 2007 06:39:26 -0400 (EDT) > Para: ARIN PPML > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > As I mentioned earlier, one of the barriers to getting management buy in on > IPv6 is the fact that the standards keep changing, and this is a good > example. To use an analogy, the financial boys won't sign off on starting > the building until they get a final floor plan. Keep rewriting the spec to > try and get it 'perfect' instead of 'good enough' and it'll still be in > redesign as the last IPv4 address goes out the door? > > What problem are we trying to solve here? Is it a valid concern, or are we > fighting the last war and blithly ignoring what will be the real problems > with IPv6. (Hint, you don't know what it is either. If it's the same > problem, it's solved. If it's something you can think of, it's probably > being solved. It's novel.) > > _______________________________________________ > 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 Tue May 29 07:18:39 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 13:18:39 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465C09C1.8050903@CC.UniVie.ac.at> Message-ID: Agree, and in addition to that, I'm convinced that it is not good at all that somebody else different than the RIRs start allocating addresses. Regards, Jordi > De: "Wilfried Woeber, UniVie/ACOnet" > Organizaci?n: UniVie - ACOnet > Responder a: > Fecha: Tue, 29 May 2007 11:08:49 +0000 > Para: Shane Kerr > CC: , "address-policy-wg at ripe.net" > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > Shane Kerr wrote: > > [...] >> >> If you insist on ULA central, my preferred implementation is a web >> page where you click on a button that says "give me a ULA prefix" and >> it allocates a random prefix that is not in use, and prints it on the >> screen. The only implementation question I'm not sure about is whether >> the list of allocated prefixes would be public or not; I lean towards >> making it public, although there is a (small) privacy concern. I think >> the cost of this implementation is low enough you could find a group >> of volunteers to host the system. > > My take on this is that (general) ULA is supposed to provide access > to "almost" unique prefixes. This can be managed in a distributed way. > > The "central" thing is supposed to take care of the 10^- > chance that your's is used by someone else, too. Thus it is only (more) > useful (than general ULA) if the distribution environment can guarantee > uniqueness. > > Such a guarantee involves management and review, and complaint handling > - eventually, plus protection against DoS-Attempts and legal protection. > I am not convinced that a simple (=cheap / for free) mechanism is "good > enough". > >> -- >> Shane > > Wilfried. > ********************************************** 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 rich at nic.umass.edu Tue May 29 08:39:22 2007 From: rich at nic.umass.edu (Rich Emmings) Date: Tue, 29 May 2007 08:39:22 -0400 (EDT) Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: Message-ID: On Tue, 29 May 2007, JORDI PALET MARTINEZ wrote: > I don't agree on this. > > The basic standards for IPv6 are fixed the same as with IPv4, nothing less. > The folks with the cash aren't agreeing. Even though there's no direct impact of ULA or lack of, around here, it becomes a "They still haven't decided, defer install" excuse. From jordi.palet at consulintel.es Tue May 29 08:54:16 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 14:54:16 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: I understand that, and it means we need to educate them. So is not their fault, is ours. They are not engineers :-) Regards, Jordi > De: Rich Emmings > Organizaci?n: University of Massachusetts OIT NSS > Responder a: Rich Emmings > Fecha: Tue, 29 May 2007 08:39:22 -0400 (EDT) > Para: > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > On Tue, 29 May 2007, JORDI PALET MARTINEZ wrote: > >> I don't agree on this. >> >> The basic standards for IPv6 are fixed the same as with IPv4, nothing less. >> > > The folks with the cash aren't agreeing. Even though there's no direct > impact of ULA or lack of, around here, it becomes a "They still haven't > decided, defer install" excuse. > > > _______________________________________________ > 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 bicknell at ufp.org Tue May 29 09:50:31 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 29 May 2007 09:50:31 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BE3AB.8040305@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> Message-ID: <20070529135031.GA57185@ussenterprise.ufp.org> In a message written on Mon, May 28, 2007 at 10:26:19PM -1000, Randy Bush wrote: > which is a benefit because ...? rfc 1918 space is a hack to deal with > an address space shortage. we are told ipv6 space is effectively > infinite. hence we do not need rfc 1918 style space. I think there are two gigantic fundamental flaws in this short statement. - Whatever the original goals of RFC 1918 space it has found uses and benefits far beyond simple conservation of address space. Until IPv6 provides the same benefits it will be a step backwards. Some of this is education, some is poor design. If it were just a shortage problem this discussion would have ended 5 years ago. - IPv6 space is not infinite. It's a 64-72 bit address space. That's right, subnets with > 256 hosts are very uncommon today, so we've wasted 64 bits to number 256 things. That makes the space effectively on the long end 72 bits. But more importantly, we have the T-Shirt from this exercise. Back in the 80's we gave out Class A's. It was the right thing to do. Rigid boundaries helped everyone. There were only 2000 networked computers in the world. Windows didn't exist. The address space was infinite in a world of 8 bit computers. I predict with the current allocation procedures IPv6 will be "used up" in my lifetime. I also predict the groups today getting /32's (and larger) will look like the legacy class A holders in 20 years time. When your doorknob automatically requests a ULA-C /64 when you bring it home, and your house has 2,000 of them as every individual system talks to each other we'll be looking at this quite differently. I guess I'm just constantly amazed at how our "visionaries" think small, often influenced by what they are working on right now.... ] "I went to my first computer conference at the New York Hilton about 20 ] years ago. When somebody there predicted the market for microprocessors ] would eventually be in the millions, someone else said, 'Where are they ] all going to go? It's not like you need a computer in every doorknob!'" ] ] "Years later, I went back to the same hotel. I noticed the room keys had ] been replaced by electronic cards you slide into slots in the doors." ] ] "There was a computer in every doorknob." ] Danny Hillis ] "I think there is a world market for about five computers." ] Thomas Watson, chairman of IBM 1943 ] "we are told ipv6 space is effectively infinite. hence we ] do not need rfc 1918 style space." ] Randy Bush, 2007 -- 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 jordi.palet at consulintel.es Tue May 29 09:53:35 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 15:53:35 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <6534CF9556E640FFB8565140862C0CFE@tungemaskin> Message-ID: The smaller subnet in IPv6, if you want to keep autoconfiguration and other things working, is /64, so why you want something smaller coming from the RIRs ? In addition to that, if you want to allow subneting for your customers and your own network, you need extra bits for that. So that's why typically you will get a minimum of /32 block from the RIR and customers will get a /48 from you. Regards, Jordi > De: J?rgen Hovland > Responder a: > Fecha: Tue, 29 May 2007 15:11:02 +0200 > Para: 'Roger J?rgensen' > CC: 'Stephen Sprunk' , 'ARIN PPML' , > > Asunto: RE: [address-policy-wg] Those pesky ULAs again > > > > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Roger J?rgensen > >> 1.) get ula-central and know for sure we won?t get into this issue ever >> again. >> >> 2.) administrate our own local version of ULA-central for the organization we >> co-operate with >> >> 3.) get RIR-space with all the add on administration and documentation... >> For me, only option 1.) is a real option, the other two are just >> work-around since we don?t need global routing of the address space in >> question. > > > The RIRs already provide globally unique address space. This is what you want. > Both ULA-C and the RIRs do not guarantee global routability anyway. > > ULA-L is never globally unique, so basically there is no such thing as "Unique > Locally Assigned" addresses. > > > Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get a /96 > IPv6 PA block? Why is that? > > Cheers, > > J > > ********************************************** 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 Paul_Vixie at isc.org Tue May 29 10:35:49 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Tue, 29 May 2007 14:35:49 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Tue, 29 May 2007 06:39:26 -0400." References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> Message-ID: <8978.1180449349@sa.vix.com> > As I mentioned earlier, one of the barriers to getting management buy in on > IPv6 is the fact that the standards keep changing, and this is a good > example. To use an analogy, the financial boys won't sign off on starting > the building until they get a final floor plan. Keep rewriting the spec to > try and get it 'perfect' instead of 'good enough' and it'll still be in > redesign as the last IPv4 address goes out the door? ipv4 has been in continuous redesign since 1968 or so. what your management team needs to look for isn't stasis but rather flag days. ipv6 is well past its final flag day (when all existing implementations are made "wrong" and new silicon has to be etched everywhere at once.) > What problem are we trying to solve here? Is it a valid concern, or are we > fighting the last war and blithly ignoring what will be the real problems > with IPv6. (Hint, you don't know what it is either. If it's the same > problem, it's solved. If it's something you can think of, it's probably > being solved. It's novel.) the real problems with IPv6 are those it shares with IPv4, so let's just call it "the real problems with IP". they've been argued forever and go by many names. from ppml's point of view, the right name of the biggest problem is "lack of EID/RID split". since we're using one address for both identity and location, it actually matters whether that address is universal or private, PI or PA, etc. as tli pointed out fairly early on, a solution to this problem would have added a lot more to the IP address system lifetime than adding more bits has added or will add. so, the problem isn't novel, but general recognition of the problem would certainly be novel. From randy at psg.com Tue May 29 10:49:38 2007 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2007 04:49:38 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <10709.83.108.102.34.1180426646.squirrel@webmail.e-konsult.no> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <10709.83.108.102.34.1180426646.squirrel@webmail.e-konsult.no> Message-ID: <465C3D82.90603@psg.com> > without going into details, PA/PI space is really a waste to be used in a > closed network that should never ever be directly connected to the public > Internet. You can say we are building our own very closed version of > Internet and other will be connected to us sooner or later. We need to > know we have unique address space no mather how many other organization we > connect with. and how is the ula *unique* address space different from pi/pa unique address space? randy From randy at psg.com Tue May 29 10:50:57 2007 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2007 04:50:57 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> Message-ID: <465C3DD1.50300@psg.com> >> There are no advantages to ULA (central), as I see it. Which is why I >> oppose it. > It troubles me that so many people are willing to deprive others of > something that those others consider useful just because they themselves > don't find that thing useful. nice emotional argument. all it lacks are technology and facts From kloch at kl.net Tue May 29 10:54:12 2007 From: kloch at kl.net (Kevin Loch) Date: Tue, 29 May 2007 10:54:12 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BA1B9.1060003@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> Message-ID: <465C3E94.8080309@kl.net> Randy Bush wrote: > ok, i give. if ula address space is assigned/managed by registries, how > is it actually different from pi space? They're not, they are exactly the same. > > if ipv6 space is effectively infinite (and we once thought ipv4 space > was), then what is the use of ula address space? why not just assign > vanilla ipv6 space? There seems to be a fascination with "private" address space, a result of years of abuse of rfc1918. I don't understand why ULA-L doesn't meet this requirement. If you need uniqueness, then we already have a way to request globally unique addresses. If you want "private" addresses, we have ULA-L. Maybe if we add a field to the PI template to optionally have the assignments marked "PRIVATE SPACE" or "RFC1918-STYLE-KEEP-OUT" everyone will be happy? Unlike ISP space, there is no requirement to actually announce your PI prefix. If you want "private" space, only announce it to networks you wish to talk to. - Kevin From Paul_Vixie at isc.org Tue May 29 10:58:36 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Tue, 29 May 2007 14:58:36 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Tue, 29 May 2007 09:50:31 -0400." <20070529135031.GA57185@ussenterprise.ufp.org> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> Message-ID: <12093.1180450716@sa.vix.com> > - IPv6 space is not infinite. It's a 64-72 bit address space. That's > right, subnets with > 256 hosts are very uncommon today, so we've wasted > 64 bits to number 256 things. That makes the space effectively on the > long end 72 bits. according to , i gave a talk entitled "DHCPv6 - The Case Against Stateless Autoconfig" at NAV6TF'2005. according to , there's now code in "alpha test release" status to handle DHCPv6. imho, the days of EUI64 are numbered. at home i'll probably use a /120 for each LAN. at work, we might splurge and use /96's. not that a /56 isn't enough for my house or anything, i just want the sparseful wastitude of the new address bits in IPV6 to all be at the top end. i'm using a /124 for my T1, mostly to make the PTR's easy to write and read. > But more importantly, we have the T-Shirt from this exercise. > Back in the 80's we gave out Class A's. It was the right thing > to do. was it? DEC got 16.0.0.0/8 on the basis of having 130000 employees and something like 10000 offices. they turned in five class B's to get the A. does anybody here think that DEC needed a class A by ARIN's current standards? this was a post-subnet, post-CIDR allocation. > I predict with the current allocation procedures IPv6 will be > "used up" in my lifetime. I also predict the groups today getting > /32's (and larger) will look like the legacy class A holders in > 20 years time. When your doorknob automatically requests a ULA-C > /64 when you bring it home, and your house has 2,000 of them as every > individual system talks to each other we'll be looking at this quite > differently. i include this only so that i can say, i nearly agree. unless we have an IP architecture that splits EID/RID, those doorknobs will not be globally reachable. (not that this is a problem for doorknobs but it might be for microwave ovens or something.) From randy at psg.com Tue May 29 10:59:42 2007 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2007 04:59:42 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529100000.GA16216@borg.c-l-i.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> Message-ID: <465C3FDE.7050708@psg.com> > If you insist on ULA central, my preferred implementation is a web > page where you click on a button that says "give me a ULA prefix" and > it allocates a random prefix that is not in use, and prints it on the > screen. sounds like a great idea for all of ipv6 allocation. what is the difference ula or pi/pa? randy From kloch at kl.net Tue May 29 11:04:32 2007 From: kloch at kl.net (Kevin Loch) Date: Tue, 29 May 2007 11:04:32 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529135031.GA57185@ussenterprise.ufp.org> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> Message-ID: <465C4100.8050608@kl.net> Leo Bicknell wrote: > - IPv6 space is not infinite. It's a 64-72 bit address space. That's > right, subnets with > 256 hosts are very uncommon today, so we've wasted > 64 bits to number 256 things. That makes the space effectively on the > long end 72 bits. Excellent point. I never understood why they didn't just use say 16 bits for the host portion, randomly assign an address and check for collisions before use. > I predict with the current allocation procedures IPv6 will be > "used up" in my lifetime. I also predict the groups today getting > /32's (and larger) will look like the legacy class A holders in > 20 years time. When your doorknob automatically requests a ULA-C > /64 when you bring it home, and your house has 2,000 of them as every > individual system talks to each other we'll be looking at this quite > differently. Why can't your doorknob select a ULA-L /64 and check for collisions before use? - Kevin From iljitsch at muada.com Tue May 29 11:25:40 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 17:25:40 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465C4100.8050608@kl.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <465C4100.8050608@kl.net> Message-ID: <8A8A40A7-0855-40B6-8047-8FDED00DCB45@muada.com> On 29-mei-2007, at 17:04, Kevin Loch wrote: >> - IPv6 space is not infinite. It's a 64-72 bit address space. >> That's >> right, subnets with > 256 hosts are very uncommon today, so >> we've wasted >> 64 bits to number 256 things. That makes the space effectively >> on the >> long end 72 bits. > Excellent point. I never understood why they didn't just use say 16 > bits for the host portion, randomly assign an address and check for > collisions before use. Eh... Last time I checked, that's exactly what IPv6 does. Except that the number of bits for the host portion is 64. Now 64 is a bit on the large side of course, but it does have the advantage that if the host randomly assigns itself an address where "randomly" means "borrowed from the ethernet MAC address" it will have the same exact address every time it boots without the need for anyone or anything to keep track of that address. >> When your doorknob automatically requests a ULA-C >> /64 when you bring it home, and your house has 2,000 of them as >> every >> individual system talks to each other we'll be looking at this >> quite >> differently. > Why can't your doorknob select a ULA-L /64 and check for collisions > before use? So what happens when one hotel chain merges with another and suddenly all those addresses that seemed to be unique before aren't anymore? From dlw+arin at tellme.com Tue May 29 12:01:16 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 29 May 2007 09:01:16 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <12093.1180450716@sa.vix.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> Message-ID: <20070529160116.GN5379@shell01.corp.tellme.com> On Tue, May 29, 2007 at 02:58:36PM +0000, Paul_Vixie at isc.org wrote: > according to , there's > now code in "alpha test release" status to handle DHCPv6. That's good news! > imho, the days of EUI64 are numbered. at home i'll probably use a /120 for > each LAN. at work, we might splurge and use /96's. not that a /56 isn't > enough for my house or anything, i just want the sparseful wastitude of the > new address bits in IPV6 to all be at the top end. i'm using a /124 for my > T1, mostly to make the PTR's easy to write and read. This is the most sane thing I've heard in this conversation. Frankly, I'm baffled by the hard architectural boundary at /64. Perhaps I'm limited in vision, but it's difficult to imagine a new layer-2 technology that wouldn't be entirely overwhelmed by a /64 subnet that wasn't extremely sparse. At some point, that subnet has to get to a router, and it's unusual for a router interface to be rated at more than 10x the bandwidth of the devices attached to that interface. That typically implies that there are less than 100 devices attached to that router port. Even if some new technology comes along that makes those (very loose) numbers off by a factor of 5 orders of magnitude, we're still looking at a very sparse /64. It's almost as if we're back in the early 80s, and trying to find the same potholes to step in. Didn't we learn anything from IPv4? Apparently not. We still have the EIG/RID split problem, with no solution apparent on the horizon, and we've simply made a new network protocol with more address space and incompatible headers. > > I predict with the current allocation procedures IPv6 will be > > "used up" in my lifetime. I also predict the groups today getting > > /32's (and larger) will look like the legacy class A holders in > > 20 years time. When your doorknob automatically requests a ULA-C > > /64 when you bring it home, and your house has 2,000 of them as every > > individual system talks to each other we'll be looking at this quite > > differently. > > i include this only so that i can say, i nearly agree. unless we have an > IP architecture that splits EID/RID, those doorknobs will not be globally > reachable. (not that this is a problem for doorknobs but it might be for > microwave ovens or something.) Yup. Giving someone address space in no way makes that space routable. At some point, the routing system with either break, or it will become entirely monitized and you'll need to pay to get your routes where you need them. If you are a global content provider, that's going to be a big surprise. (As a side note, I wonder if the economics of this will work out such that shorter prefixes cost less than longer ones. That might make a big incentive for aggregation. Hmm.) -David From dlw+arin at tellme.com Tue May 29 12:05:31 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 29 May 2007 09:05:31 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465C4100.8050608@kl.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <465C4100.8050608@kl.net> Message-ID: <20070529160531.GO5379@shell01.corp.tellme.com> On Tue, May 29, 2007 at 11:04:32AM -0400, Kevin Loch wrote: > Leo Bicknell wrote: > > > - IPv6 space is not infinite. It's a 64-72 bit address space. That's > > right, subnets with > 256 hosts are very uncommon today, so we've wasted > > 64 bits to number 256 things. That makes the space effectively on the > > long end 72 bits. > > Excellent point. I never understood why they didn't just use say 16 > bits for the host portion, randomly assign an address and check for > collisions before use. Good question. Appletalk "just worked" under most conditions, and it worked this way, although in a smaller address space. It was never designed as a viable global network protocol, mostly due to lack of address space, but also due to it's internal limits in scaling routing. Golly, IPv6 is just like that, but without the lack of space! Routing's still broken, and hacks like ULA-C certainly aren't helping. -David From drc at virtualized.org Tue May 29 12:27:34 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 29 May 2007 09:27:34 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529160116.GN5379@shell01.corp.tellme.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> Message-ID: <1ABBEF0F-C45A-482D-8112-F59E59E420AE@virtualized.org> > Frankly, I'm baffled by the hard architectural boundary at /64. "Stateless auto-configuration" (whether you want it or not). > Perhaps I'm limited in > vision, but it's difficult to imagine a new layer-2 technology that > wouldn't > be entirely overwhelmed by a /64 subnet that wasn't extremely sparse. The assumption was the lower 64 bits would be _extremely_ sparse. > It's almost as if we're back in the early 80s, and trying to find the > same potholes to step in. Didn't we learn anything from IPv4? Yes, but we chose not to apply our lessons. > Apparently not. We still have the EIG/RID split problem, with no > solution apparent on the horizon, and we've simply made a new network > protocol with more address space and incompatible headers. Yes. We've placed ourselves into a situation where we need to create a new, alternate Internet, and migrate everyone over to that new Internet, yet have provided no real incentive to do so. It is somewhat odd -- we're stuck with the same constraints we have with IPv4 in terms of routing architecture and implementation and naming, yet every application must still change (but not in a good way) and there is no backwards compatibility at all. For a short time, I thought there might be a way of using the advantages of an EID/RID split as a way of giving end users something they can't easily get with IPv4 (namely, easy multi-homing, transparent "renumbering", and trivial mobility), but that effort has run into the IETF swamp and appears to have gotten a bit bogged down. I have lost hope of anything productive happening in any sort of reasonable timeframe. So, since there isn't a carrot (at least one that people care about), we're left with the stick of running out of the IPv4 free pool. Of course, that isn't really a stick since, as people have pointed out, the Internet isn't going to stop when the free pool is exhausted, rather people will simply adjust. Ah well, maybe NAT isn't so bad... Rgds, -drc From owen at delong.com Tue May 29 12:40:19 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2007 09:40:19 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> Message-ID: <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> On May 29, 2007, at 2:31 AM, Iljitsch van Beijnum wrote: > On 29-mei-2007, at 11:18, Shane Kerr wrote: > >> There are no advantages to ULA (central), as I see it. Which is why I >> oppose it. > > It troubles me that so many people are willing to deprive others of > something that those others consider useful just because they > themselves don't find that thing useful. > > Quote from dr. Phil: "If your kid wakes up at night and says 'daddy > I'm thirsty can I get some water' you don't say 'I'm not thirsty, you > don't need water', you give the kid a glass of water. Everyone has > different needs." Right, but, if your kid wakes up at night and says "Daddy, I've got a hankering to blow stuff up. Can I get a grenade?" You don't just hand the kid a live grenade, whether you like to blow stuff up or not. Most of the opposition to ULA-C is because we see real downsides to it and don't see ANY upsides. Advantages of ULA-C (even to those who claim there are some): Virtually none. Some minor configuration convenience if a number of unsubstantiated assumptions are hard-coded into routers. Disadvantages of ULA-C: Nothing prevents it from becoming another form of provider-independent routed space on the internet. The policies for ULA-C are likely to be different from the policies for PI. If both address spaces function in an equivalent manner and have different policies to obtain/maintain the addresses, then the policy mechanism is undermined. etc. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From iljitsch at muada.com Tue May 29 12:58:47 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 18:58:47 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: On 29-mei-2007, at 18:40, Owen DeLong wrote: > Advantages of ULA-C (even to those who claim there are some): > Virtually none. I'm sure you don't mind the plane renumbering in flight when it switches from one satellite connection to the next. Myself, I'd like to see the flight systems to have stable addressing regardless of the orientation of the satellite antennas. > Disadvantages of ULA-C: I can't believe you keep pounding on this dead horse. These are PRIVATE addresses. Period. From Paul_Vixie at isc.org Tue May 29 13:14:32 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Tue, 29 May 2007 17:14:32 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Tue, 29 May 2007 09:36:07 MST." <465C5677.3040607@bogus.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> Message-ID: <30761.1180458872@sa.vix.com> > You're always going to be looking at a sparse /64, you've got > 18446744073709551616 addresses. But you need it if you want to do eui64. sadly, eui64 is in the standard, and it would take a flag day to remove it. so while i expect folks to switch from stateless address autoconfiguration to DHCPv6 to get some auditing and to be able to set config knobs like name server lists and so on, i believe that everybody will always use /64's for LANs, since some embedded devices will always demand EUI64. so there's no way to get the address space back, and IPv6 is as leo said, effectively the same size as a 72 bit address space. (note well, there was an urban legend about the /64 boundary being present in silicon on some switch or router, but in my own testing, every C and J router i laid hands on was able to work with /96 or /120 netmasks on connected LAN interfaces, forward to them without using more CPU time than a connected /64, receive routes, and advertise routes. so at the moment, "/64 is hardwired into router silicon" is just an urban legend to me. if you want to argue this point, plz provide session traces and rev levels.) From dlw+arin at tellme.com Tue May 29 13:25:58 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 29 May 2007 10:25:58 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: <20070529172557.GS5379@shell01.corp.tellme.com> On Tue, May 29, 2007 at 06:58:47PM +0200, Iljitsch van Beijnum wrote: > > Advantages of ULA-C (even to those who claim there are some): > > Virtually none. > > I'm sure you don't mind the plane renumbering in flight when it > switches from one satellite connection to the next. Myself, I'd like > to see the flight systems to have stable addressing regardless of the > orientation of the satellite antennas. > > > Disadvantages of ULA-C: > > I can't believe you keep pounding on this dead horse. These are > PRIVATE addresses. Period. Uh, neither of those reasons undermines the solution others have proposed: use PI space. You can always just not announce some part (or all) of your space. That would make it private. ULA-C sounds to me like a request to the guys who spin silicon to help people keep from screwing up their router configs. If someone can't manage to filter their BGP such that they keep some (or all) of their space private, I don't see why Cisco, Juniper, et al., need to do that for them. -David From randy at psg.com Tue May 29 13:31:05 2007 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2007 07:31:05 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529172557.GS5379@shell01.corp.tellme.com> References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: <465C6359.7020508@psg.com> > ULA-C sounds to me like a request to the guys who spin silicon to help > people keep from screwing up their router configs. If someone can't > manage to filter their BGP such that they keep some (or all) of their > space private, I don't see why Cisco, Juniper, et al., need to do > that for them. or that the router vendors will do a more reliable job of it, given the complexity of knowing what is a site border and what is not, especially when folk are saying that there are actually multiple entities inside the border. and do we really want the vendors to hard-code address filters in the sillycone? this is the path on which site-local died, and the death was a good thing. RFC 1925 2(11) ?Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.? randy From iljitsch at muada.com Tue May 29 13:32:27 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 19:32:27 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529172557.GS5379@shell01.corp.tellme.com> References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: On 29-mei-2007, at 19:25, David Williamson wrote: >>> Disadvantages of ULA-C: >> I can't believe you keep pounding on this dead horse. These are >> PRIVATE addresses. Period. > Uh, neither of those reasons undermines the solution others have > proposed: use PI space. That's like saying people can use real money instead of monopoly money. I really don't get this. Did you guys bet a lot of money that there would never be ULA-C or something? If you don't like it, don't use it yourself and filter it, but PLEASE don't whine about it. From owen at delong.com Tue May 29 13:38:09 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2007 10:38:09 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> On May 29, 2007, at 10:32 AM, Iljitsch van Beijnum wrote: > On 29-mei-2007, at 19:25, David Williamson wrote: > >>>> Disadvantages of ULA-C: > >>> I can't believe you keep pounding on this dead horse. These are >>> PRIVATE addresses. Period. > >> Uh, neither of those reasons undermines the solution others have >> proposed: use PI space. > > That's like saying people can use real money instead of monopoly > money. I really don't get this. Did you guys bet a lot of money > that there would never be ULA-C or something? > Um, no. It's like saying that counterfeit money is bad and we'd rather not create a sponsored system for printing it. Oh, wait, the treasury department (at least in the US, and, I'm betting whoever is the responsible agency in most other governments) feels that way. > If you don't like it, don't use it yourself and filter it, but > PLEASE don't whine about it. That's like saying if you don't like counterfeit currency, don't use it yourself, but, don't complain about the damage it does to your economy. Right. Owen -------------- 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 Tue May 29 13:39:11 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 29 May 2007 10:39:11 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: <20070529173911.GW5379@shell01.corp.tellme.com> On Tue, May 29, 2007 at 07:32:27PM +0200, Iljitsch van Beijnum wrote: > That's like saying people can use real money instead of monopoly > money. I really don't get this. Did you guys bet a lot of money that > there would never be ULA-C or something? > > If you don't like it, don't use it yourself and filter it, but PLEASE > don't whine about it. Calling a debate "whining" is a bit rude. My "whining" isn't intended to change your mind - I don't think any argument I make is likely to do that. My argument, however, is that there's no problem solved by ULA-C that can't be solved by PI space, and the creation of ULA-C would entirely undermine the RIR-based PI system. That latter possibility is the thing that worries those of us who are whining. That seems like a "bad idea". If you seriously think that ULA-C is entirely orthogonal to PI space, and will have zero impact on the usage of PI space...well...we'll have to agree to disagree. All of this, of course, distracts from the real underlying problem, as Mr. Vixie points out. Okay, I think that's my quote of posts to ppml for the day. Time to let someone else add their thoughts. -David From jeroen at unfix.org Tue May 29 13:51:19 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 29 May 2007 18:51:19 +0100 Subject: [ppml] ULA Registry Message-ID: <465C6817.4060701@spaghetti.zurich.ibm.com> [Major cross post, set reply-to to NANOG, please honor it... ] [Note: I am not talking about ULA Central here, though it could apply] To stop the pesky emails about ULA, I hereby present a (partial) solution to this problem. We have ULA as per RFC4193. With a little math one can generate a ULA prefix sized /48 which is most likely globally unique. According to the RFC with 10.000 connections the collision probability is still a huge 4.54*10^-05. Some people have expressed a problem with this, especially when they want to use the generated ULA prefix for their large organization. The simple, cheap and quick solution: a ULA registry. This comes close to ULA-Central, but what we do is simply make a list of the "in use" ULA's, without any allocation policies whatsoever except: first come first serve and no cash to pay. The tool is here: http://www.sixxs.net/tools/grh/ula/ The page allows one to generate a ULA based on a given MAC address (multicast + locally defined + unregistered are not accepted) and then register it. The Name + Email are mandatory to restrict abuse a little bit. Email is not shown, except in whois and can be used to possible contact people who are leaking ULA prefixes. Note, it is indeed a _partial_ solution. When somebody still generates the same ULA prefix and does not check the list you can still collide. As this is primarily a problem for big organizations, they should be checking this list for collisions and registering their prefix when they see that they have a need for that. The list is available from the website, but also per whois.sixxs.net which is now serving up fd00::/8. It does not cover ULA-C (fc00::/8). As SixXS is a private hobbyproject kind of thing, we of course are not liable for anything that this might cause to you, your family, company etc. But enjoy it nevertheless. Full copies of the list in inet6num format are available from the site. Greets, Jeroen PS: GRH still classifies ULA's as "BAD" of course PPS: Thanks to Peter van Dijk for the multicast/locally defined MACs PPPS: Folks registering prefixes like crazy will nicely get locked out automatically, so don't even try... PPPPS: Thanks to SUZUKI Shinsuke and Holger Zuleger for the generator. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From rich at nic.umass.edu Tue May 29 14:52:20 2007 From: rich at nic.umass.edu (Rich Emmings) Date: Tue, 29 May 2007 14:52:20 -0400 (EDT) Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <8978.1180449349@sa.vix.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <8978.1180449349@sa.vix.com> Message-ID: On Tue, 29 May 2007, Paul_Vixie at isc.org wrote: > ipv4 has been in continuous redesign since 1968 or so. what your management > team needs to look for isn't stasis but rather flag days. ipv6 is well past > its final flag day (when all existing implementations are made "wrong" and > new silicon has to be etched everywhere at once.) It's an excuse, not a valid one. IPv4 updates get applied because it's started, and those changes don't impact the running enviroment. IPv6 is not started, so those changes are an excuse "It's not ready yet. Now stop bothering me and fix my computer" I should mention here, by means of disclaimer, is my comments about management reflect a variety of shops, and not my current one, mostly we're stuffed here waiting for full vendor support _for the applications we need_. I've been running a dual stack for two years, in a limited fashion. It's not scaleable yet. In the late 90's not a purchase order went out without "Must be Y2K compliant" stamped on it (for whatever it was worth). These days, the PO's need to go out "Must be IPv6 compliant" -- except that 1/1/2000 was a hard date, and IPv6 isn't. We're still getting new network gear that isn't fully supporting IPv6, and in some spaces, there's just not a choice. > the real problems with IPv6 are those it shares with IPv4, so let's just call > it "the real problems with IP". they've been argued forever and go by many > names. from ppml's point of view, the right name of the biggest problem is > "lack of EID/RID split". since we're using one address for both identity and > location, it actually matters whether that address is universal or private, > PI or PA, etc. as tli pointed out fairly early on, a solution to this > problem would have added a lot more to the IP address system lifetime than > adding more bits has added or will add. so, the problem isn't novel, but > general recognition of the problem would certainly be novel. Nothing is perfect, but it's easier to change direction once things are irrevokably moving forward, that to get it moving to start. Apropos of nothing: http://www.caida.org/analysis/topology/as_core_network/ipv6.xml (slightly dated) From randy at psg.com Tue May 29 14:56:18 2007 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2007 08:56:18 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <8978.1180449349@sa.vix.com> Message-ID: <465C7752.5080206@psg.com> > In the late 90's not a purchase order went out without "Must be Y2K > compliant" stamped on it (for whatever it was worth). These days, the PO's > need to go out "Must be IPv6 compliant" -- except that 1/1/2000 was a hard > date, and IPv6 isn't. and, more importantly, the belief that money was effectively infinite (inda like ipv6 address space:) is no longer widely held. we actually have to *justify* spending it on a hard to perceive and no clear profit major change. randy From iljitsch at muada.com Tue May 29 14:59:15 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 20:59:15 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> Message-ID: <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> On 29-mei-2007, at 19:38, Owen DeLong wrote: >>> Uh, neither of those reasons undermines the solution others have >>> proposed: use PI space. >> That's like saying people can use real money instead of monopoly >> money. I really don't get this. Did you guys bet a lot of money >> that there would never be ULA-C or something? > Um, no. It's like saying that counterfeit money is bad and we'd > rather not > create a sponsored system for printing it. Your view that ULA-C is like counterfeit money while it's more like monopoly money nicely illustrates the entire point (or rather, pointlessness) of this discussion. On 29-mei-2007, at 19:39, David Williamson wrote: >> If you don't like it, don't use it yourself and filter it, but PLEASE >> don't whine about it. > Calling a debate "whining" is a bit rude. Whether DHCPv6 is better than stateless autoconfiguration is a debate. The people who think DHCPv6 is the way to go are wrong, but there is no harm in them thinking that: they can run DHCPv6 while I run stateless autoconfig and everyone is happy. The whole ULA-C thing is not a debate. The anti-group is trying to wear the pro-group down by repeating the same few arguments that don't make a whole lot of sense over and over, and try to deprive the pro-group from something that group feels is useful based on fear, uncertainty and doubt. It's bullying. > My "whining" isn't intended to change your mind - I don't think any > argument I make is likely to do that. My argument, however, is that > there's no problem solved by ULA-C that can't be solved by PI space, That's not really true, because ULA is recognizable as such, while PI space is presumed to be routable, even if routing it isn't desired. But more importantly, ULA-C would be exceedingly easy to get, while PI is exceedingly hard to get. > and the creation of ULA-C would entirely undermine the RIR-based PI > system. If only that were true. Unaggregatable PI is something we know can't work if widely deployed. But the realities of the RIR system are such that this is irrelevant. The only way ULA-C can effectively become PI is if everyone (for a large value of "everyone") accepts those advertisements. That will only happen if everyone thinks its a good idea, i.e., when you guys change your mind. Since there doesn't seem to be much danger of that happening (and people like me, who are also quite stubborn, are also against this) I don't see the problem. And IF we all change our minds, then obviously we'd have a good reason for that, wouldn't we? > If you seriously think that > ULA-C is entirely orthogonal to PI space, and will have zero impact > on the usage of PI space...well...we'll have to agree to disagree. You can agree to disagree on things that are a matter of opinion or believe. You can't agree to disagree on an engineering decision with global impact. > All of this, of course, distracts from the real underlying problem, as > Mr. Vixie points out. Identifier/locator split, you mean? There was no way they could have designed and implemented that successfully 25 years ago: not enough giants to stand on the shoulders of. We can probably do those parts now, but I'm not so sure about being able to deploy it, and if it's actually going to buy us something if we manage that. From dlw+arin at tellme.com Tue May 29 15:08:02 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 29 May 2007 12:08:02 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> Message-ID: <20070529190802.GZ5379@shell01.corp.tellme.com> On Tue, May 29, 2007 at 08:59:15PM +0200, Iljitsch van Beijnum wrote: > But more importantly, ULA-C would be exceedingly easy to get, while > PI is exceedingly hard to get. I wasn't going to post again today to this list, but I cannot let blatantly incorrect statements go by. PI is not hard to get, although your experience may vary by region. My org holds a PI /48, and it took me 2 days of duration and ten minutes of effort to receive it. That's nearly trivial, in my book. -David From jordi.palet at consulintel.es Tue May 29 16:03:50 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 22:03:50 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529190802.GZ5379@shell01.corp.tellme.com> Message-ID: Agree, in ARIN region is not difficult to get, but in other two regions (LACNIC and RIPE NCC) is still impossible. However more difference to point to is that using PI for a function such as the one covered by ULA-Central is wasting space. It seems to me that this is quite contradictory for those folks that decided that /48 is too much for end sites and wanted to change it to /56. Some seems to be in favor of not "wasting" space, but when it comes to ULA-Central, the saving part is the less important one, even if implementing ULA-central will not damage at all to those that don't want to use it. Regards, Jordi > De: David Williamson > Responder a: > Fecha: Tue, 29 May 2007 12:08:02 -0700 > Para: Iljitsch van Beijnum > CC: ARIN PPML , "address-policy-wg at ripe.net" > > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > On Tue, May 29, 2007 at 08:59:15PM +0200, Iljitsch van Beijnum wrote: >> But more importantly, ULA-C would be exceedingly easy to get, while >> PI is exceedingly hard to get. > > I wasn't going to post again today to this list, but I cannot let > blatantly incorrect statements go by. PI is not hard to get, although > your experience may vary by region. My org holds a PI /48, and it > took me 2 days of duration and ten minutes of effort to receive it. > That's nearly trivial, in my book. > > -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 jrhett at svcolo.com Tue May 29 16:16:32 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 29 May 2007 13:16:32 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070524051442.GA5379@shell01.corp.tellme.com> References: <428E6440939F654F8BD72C49361E855FB94EE7@host252.iconnect-corp.com> <20070523154211.GK5379@shell01.corp.tellme.com> <20070524015356.GB77370@ussenterprise.ufp.org> <20070524051442.GA5379@shell01.corp.tellme.com> Message-ID: <8241690E-EF53-4520-A544-6EDDAB031A74@svcolo.com> On May 23, 2007, at 10:14 PM, David Williamson wrote: > I really think people who think renumbering is easy don't work for > ASP-like companies. There's a few specific challenges that make it a > thorny problem. A large amount of embedded addresses in vpns and > customer-controlled ACLs are just a nightmare, especially when NAT > isn't an option. I'm not aware of anyone saying that renumbering is easy. I personally was suggesting that situations where renumbering is difficult are (a) fairly rare and (b) easier for the business to identify than ARIN and (c) are the businesses problem to solve, not ARIN. If you run a business that requires large volumes of X, then as said business you identify the source of X as a risk and determine how to best address that problem. Most of the comments made in this thread seem to indicate that ARIN should be responsible for the businesses dependancy, and that ARIN should solve this problem for the business at the detriment of every business who must maintain a full routing table on their big iron. I disagreed. I would also like to point out that ARIN's current policy makes it very trivial to qualify under the multihoming requirement, and the cost of doing this is already borne by every business who is large enough to have this risk, and thus neglible. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Tue May 29 16:17:27 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 29 May 2007 13:17:27 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <5777864ED563124EA7898F96C407BFF305178113@whexchmb01.bsna.bsroot.bear.com> References: <5777864ED563124EA7898F96C407BFF305178113@whexchmb01.bsna.bsroot.bear.com> Message-ID: <085B7B01-4B59-4F48-9369-66A89878BD43@svcolo.com> On May 24, 2007, at 5:47 AM, Maruottolo, Richard wrote: > It can be done but there are in many cases significant hurdles and > potential risks to the firm renumbering that need to be handled. I > have > lost many hours of sleep on weekends doing such migrations for large > firms where the impact of a mistake or downtime in financial lost is > enormous. Saying the *rest* can take months is an understatement in > many cases. Right. So the business knows this and has identified how they want to address this dependancy, yes? -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From michael.dillon at bt.com Tue May 29 17:09:07 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 29 May 2007 22:09:07 +0100 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529160116.GN5379@shell01.corp.tellme.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com><000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com><00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com><28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no><007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com><465BA1B9.1060003@psg.com><031b01c7a1ca$64904270$dc128953@kantoor.computel.nl><465BE3AB.8040305@psg.com><20070529135031.GA57185@ussenterprise.ufp.org><12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> Message-ID: > This is the most sane thing I've heard in this conversation. > Frankly, I'm baffled by the hard architectural boundary at > /64. Perhaps I'm limited in vision, The IETF working groups are over there http://www.ietf.org This is the ARIN public policy where we make policy on numbering resources that have been defined by the IETF and delegated to us by IANA. If you don't like the way that the IETF designs things, head over to their working groups and tell them, in excruciating detail, why they are wrong and you are right. You can even write an Internet draft submit it. As far as I am concerned, the minimum size of address allocation for a single IPv6 interface on a single device is /64. That's the way the IETF designed it and documented it in their RFCs. Whether or not I choose to use Ethernet MACs (48 bits) or random numbers (64 bits) or Paul's choice of a /124 for that /64 identifier is irrelevant. The IETF designed it the way it is and ARIN should not change that. Paul can change it if he wants to because it is his network, and therefore his rules. And Paul also has the skill to fix things up if the law of unintended consequences bites him some day. ARIN needs to be more prudent and stick closer to the RFCs. --Michael Dillon From michael.dillon at bt.com Tue May 29 17:13:47 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 29 May 2007 22:13:47 +0100 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com><000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com><00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com><28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no><007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com><465BA1B9.1060003@psg.com><031b01c7a1ca$64904270$dc128953@kantoor.computel.nl><465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: > The policies for ULA-C are likely to be different from > the policies for PI. ULA-C doesn't exist. There is not even a current Internet draft to define what the acronym stands for. If any RIRs create a policy on that basis, then it will be the beginning of the end of the RIR system. The RIRs are supposed to be stewards, prudently managing a shared resource. --Michael Dillon From Ed.Lewis at neustar.biz Tue May 29 17:36:39 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 29 May 2007 17:36:39 -0400 Subject: [ppml] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE 6B52F36@muada.com><000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com><00E EA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com><28749.83.109.229.46.118035637 1.squirrel@webmail.e-konsult.no><007601c7a1a3$35dc4e00$343816ac@atlanta.po lycom.com><465BA1B9.1060003@psg.com><031b01c7a1ca$64904270$dc128953@kantoo r.computel.nl><465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: I've been curious about the ULA Central issue and finally had a chance to read the most recent (but expired) draft maintained on the tools.ietf.org site. Being curious about why it is an expired draft, I found this message in the archives for the WG and read through the follow ups to it. http://www1.ietf.org/mail-archive/web/ipv6/current/msg04751.html I have also sent mail to the editors in an attempt to find out why the draft is where it is. There isn't anything in the follow ups that seem to say that ULA is a dead idea - a few messages support going forward then a few messages question the need for ULA in light of an ARIN proposal in 2005. My opinion on this is that there is nothing for ARIN to do with respect to this, nothing tangible to discuss. I can't find anything on the IETF site that indicates if there is any future movement to be expected either. From my read of the expired draft, I don't see a reason that it would be progressed. That is, it seems to be leading down the same dead end as other scoped addresses (site local). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From jordi.palet at consulintel.es Tue May 29 17:52:04 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 23:52:04 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: That's broken. As it has been stated in previous messages some days ago, RIR communities can do whatever they want, especially if IETF fails. I'm doing IETF work, but it is clear that some times, for whatever reasons is too slow, or even fails. This community has the right to bypass that if required. And one more demonstration that this is broken: All the RIRs did 4-byte-ASN policies when no RFCs where available. As you can see the RIR system is still working. So yes, I will much prefer to have an RFC, and this is the way we are going, but nothing precludes to go in parallel, as it has been done in the 4-byte-ASN, and probably some other times I guess. And, in the worst case, if the IETF fails again on this (I'm sure will not be the case this time), we could always go for a global policy to instruct IANA to delegate that resource to the RIRs. Regards, Jordi > De: > Responder a: > Fecha: Tue, 29 May 2007 22:13:47 +0100 > Para: , > Conversaci?n: [ppml] [address-policy-wg] Those pesky ULAs again > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > >> The policies for ULA-C are likely to be different from >> the policies for PI. > > ULA-C doesn't exist. There is not even a current Internet draft to > define what the acronym stands for. If any RIRs create a policy on that > basis, then it will be the beginning of the end of the RIR system. > > The RIRs are supposed to be stewards, prudently managing a shared > resource. > > --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 jordi.palet at consulintel.es Tue May 29 17:58:31 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 23:58:31 +0200 Subject: [ppml] Those pesky ULAs again In-Reply-To: Message-ID: Hi Ed, I can confirm that there is a group of folks, including the original authors, working on a new version to be submitted before the next IETF deadline and presented in the Chicago meeting. The policy proposal about ULA-Central will then be updated in all the regions and submitted to ARIN (the only region that still don't had a proposal on this). Regards, Jordi > De: Edward Lewis > Responder a: > Fecha: Tue, 29 May 2007 17:36:39 -0400 > Para: > CC: > Asunto: Re: [ppml] Those pesky ULAs again > > I've been curious about the ULA Central issue and finally had a > chance to read the most recent (but expired) draft maintained on the > tools.ietf.org site. Being curious about why it is an expired draft, > I found this message in the archives for the WG and read through the > follow ups to it. > > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04751.html > > I have also sent mail to the editors in an attempt to find out why > the draft is where it is. There isn't anything in the follow ups > that seem to say that ULA is a dead idea - a few messages support > going forward then a few messages question the need for ULA in light > of an ARIN proposal in 2005. > > My opinion on this is that there is nothing for ARIN to do with > respect to this, nothing tangible to discuss. I can't find anything > on the IETF site that indicates if there is any future movement to be > expected either. From my read of the expired draft, I don't see a > reason that it would be progressed. That is, it seems to be leading > down the same dead end as other scoped addresses (site local). > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Sarcasm doesn't scale. > _______________________________________________ > 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 Ed.Lewis at neustar.biz Tue May 29 18:04:13 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 29 May 2007 18:04:13 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: Message-ID: At 11:52 PM +0200 5/29/07, JORDI PALET MARTINEZ wrote: >And, in the worst case, if the IETF fails again on this (I'm sure will not What is meant by the "IETF fails...on this"? The IETF prides itself on allowing any idea to be presented but requiring a consensus to promote meritorious ideas. Just because a draft has appeared doesn't mean the idea was a good one - I should know, I've written a whole lot of expired drafts myself (and even some obsoleted RFCs). It would be more convenient if the IETF documented why a draft is left to expire, so that future efforts don't repeat mistakes made before. What I *sense* is happening here is that the RIRs are being used to do an end-run around the IETF process. This 'sense' is based on reading the draft (and seeing that this is along the lines of site local), looking at the mail list archives (which lacks overwhelming support to promote this), and the hint that the IETF is failing to promote ULA (perhaps that is just from the choice of words). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From iljitsch at muada.com Tue May 29 18:06:48 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 30 May 2007 00:06:48 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: Message-ID: <4A8DC856-233A-4C16-9E65-1F5100392E77@muada.com> On 29-mei-2007, at 23:52, JORDI PALET MARTINEZ wrote: > That's broken. As it has been stated in previous messages some days > ago, RIR > communities can do whatever they want, especially if IETF fails. > I'm doing > IETF work, but it is clear that some times, for whatever reasons is > too > slow, or even fails. This community has the right to bypass that if > required. The IETF is far from perfect, but I'm not quite convinced that the RIRs stepping in when the IETF doesn't produce the desired results is going to work well. > And one more demonstration that this is broken: All the RIRs did 4- > byte-ASN > policies when no RFCs where available. There had been a draft for more than 5 years, the reason that there was no RFC was a process particularity (can't publish a routing RFC without there being interoperable implementations), not lack of consensus on any technical issue. > So yes, I will much prefer to have an RFC, and this is the way we > are going, What exactly is the way we are going? From bicknell at ufp.org Tue May 29 18:20:33 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 29 May 2007 18:20:33 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <30761.1180458872@sa.vix.com> References: <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> Message-ID: <20070529222033.GA83891@ussenterprise.ufp.org> In a message written on Tue, May 29, 2007 at 05:14:32PM +0000, Paul_Vixie at isc.org wrote: > sadly, eui64 is in the standard, and it would take a flag day to remove it. I disagree it takes a flag day to remove it, your own experience is the key: > (note well, there was an urban legend about the /64 boundary being present > in silicon on some switch or router, but in my own testing, every C and J > router i laid hands on was able to work with /96 or /120 netmasks on > connected LAN interfaces, forward to them without using more CPU time than > a connected /64, receive routes, and advertise routes. so at the moment, > "/64 is hardwired into router silicon" is just an urban legend to me. if > you want to argue this point, plz provide session traces and rev levels.) If DHCP6 works (and although I haven't used it lately, seems like good progress is being made) we're on the right track. All we need is for Comcast / AT&T / Time Warner and other large CableCo's to say "we're going to give each house a routed /120, and the router will do DHCP6 for it" and we're good to go. People can still use stateless autoconfig where they want it, I suspect it will go the way of the dodo. Conversely, it would be rather trivial to add random address assignment to IPv4. ICMP router solicitation, auto configure into the subnet, randomly assign a IP, look for a collision. AppleTalk did it 15 years ago. Worked good for small deployments. Would be fun to write the code and check it into several distros.... -- 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 jordi.palet at consulintel.es Tue May 29 18:22:40 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 30 May 2007 00:22:40 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: You're right, it is a matter or wording. I should have said "IETF community fails to reach consensus". Note that I've not been instructed at all by the IETF or anything like that on anything about this. I just saw the need for ULA-central and started wondering what alternatives we have to bring it back. Nothing else. What failed previously ... IESG can say, I only have hints, and points to something not good in my opinion, but I don't want to talk here about something that I don't know completely. Regards, Jordi > De: Edward Lewis > Responder a: > Fecha: Tue, 29 May 2007 18:04:13 -0400 > Para: > CC: , > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > At 11:52 PM +0200 5/29/07, JORDI PALET MARTINEZ wrote: > >> And, in the worst case, if the IETF fails again on this (I'm sure will not > > What is meant by the "IETF fails...on this"? The IETF prides itself > on allowing any idea to be presented but requiring a consensus to > promote meritorious ideas. Just because a draft has appeared doesn't > mean the idea was a good one - I should know, I've written a whole > lot of expired drafts myself (and even some obsoleted RFCs). > > It would be more convenient if the IETF documented why a draft is > left to expire, so that future efforts don't repeat mistakes made > before. > > What I *sense* is happening here is that the RIRs are being used to > do an end-run around the IETF process. This 'sense' is based on > reading the draft (and seeing that this is along the lines of site > local), looking at the mail list archives (which lacks overwhelming > support to promote this), and the hint that the IETF is failing to > promote ULA (perhaps that is just from the choice of words). > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Sarcasm doesn't scale. ********************************************** 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 alh-ietf at tndh.net Tue May 29 20:05:56 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 29 May 2007 17:05:56 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> Message-ID: <1b7801c7a24e$4c0da560$e428f020$@net> Consolidated response to this barrage: Randy Bush wrote: > ok, i give. if ula address space is assigned/managed by registries, how > is it actually different from pi space? Policy expectations. If I get PI space from a registry, the ISP I call on knows I had to do some level of justification to get that. If I show up trying to get a ULA space routed, they know that took no justification, making it easier to refuse. > > if ipv6 space is effectively infinite (and we once thought ipv4 space > was), then what is the use of ula address space? why not just assign > vanilla ipv6 space? If people could get PI everywhere, without expectation that it would ever be routed, then your argument about equating them would hold for some uses. PI is not globally available, and even when it is the justification is based on need to route that much space. > > i am very confused by all the smoke and am trying to find the core of > this stuff. > Stirring the smoke around is not helping ... There is a very basic policy issue here, can an organization get space without being tied to a service provider? In some areas that is possible, if one is willing to subject themselves to scrutiny. ULA-L allows that organization to get space with a probability of uniqueness, while ULA-C provides their management 'more assurance' that there will not be a cost down the road related to partnerships or m&a. The other issue that is being mixed in is how and where filtering is done. Yes an organization with PI space could firewall off a portion of that and have a similar effect for some purposes. At that point you are trusting that there are no operational errors in the firewall config over time, and that it can keep up with the attacks. Using the ULA approach, -there is no route- so there is less work for the firewall to do, and a very simple filter that implemented by both the organization and the ISP. If the need to firewall off machines does not map to subnets though, the complexity of the firewall rules may exceed the ability of the products on the market. This is a trade-off issue where use of ULA space alongside either PA or PI allows the complexity to be spread out over device management, where those that don't need external access are only accessible using the ULA prefix. Jeroen Massar wrote: > > ULA space should be !A'ed out by routers per default and have a > > special switch to enable forwarding for them. Randy Bush wrote: > you are asking that routers hard code the association between > routability and address space. and next you only want this at site > border routers and not 'internal' routers. this was called site-local, > and was soundly rejected as > a disaster in the making. There is a big difference between hard-coding and default configurations. Strict RPF is another thing that should be 'on by default'; because in both cases the people that need it turned on are not aware they need it, while those that need it turned off are smart enough to turn the knob (and if they are not smart enough they probably really need it turned on). SL was killed off due to fear mongering, not because it was it was a disaster. There were no rational arguments, just a mob of chicken-little screaming. There was nothing in the spec that said the bits had to be zero, but there was also nothing in the spec that said they should not be. Rather than fixing it by telling people to use non-zero values, the mob said 'kill the monster because we are afraid...'. Iljitsch van Beijnum > It troubles me that so many people are willing to deprive others of > something that those others consider useful just because they > themselves don't find that thing useful. Get used to it because some of the people on these lists are control freaks that just want to deprive others. Shane Kerr wrote: > But I do not think ULA central is useful to anyone. You are entitled to your opinion. > > Even if ULA central is useful, I don't think it is something the RIRs > need to be involved in. To avoid the perpetual arguments about ULA-C vs. PI, it would be best if both were handled by the same organization to avoid the additional nonsense about an end run around the process. There is also the case that only organizations that really care would even be asking for ULA-C, and if they care enough they would be willing to become RIR members if need be. Additional recurring revenue for what is essentially a one-time effort should be enough of a reason for the RIR's to be involved. Rich Emmings wrote: > As I mentioned earlier, one of the barriers to getting management buy in > on > IPv6 is the fact that the standards keep changing, and this is a good > example. To use an analogy, the financial boys won't sign off on > starting > the building until they get a final floor plan. Keep rewriting the spec > to > try and get it 'perfect' instead of 'good enough' and it'll still be in > redesign as the last IPv4 address goes out the door? > > What problem are we trying to solve here? Is it a valid concern, or are > we > fighting the last war and blithly ignoring what will be the real > problems > with IPv6. (Hint, you don't know what it is either. If it's the same > problem, it's solved. If it's something you can think of, it's probably > being solved. It's novel.) The standards are not being changed here, it is policy, and policy changes all the time. The problem in this thread is that people keep mixing various policy arguments to justify their position on why this space is needed or not. There are several problems at hand, and various people don't want some of them solved. This results in the confused discussion that keeps happening, and will keep happening until the lack of IPv4 space forces a resolution. Unfortunately crisis based resolutions are not well thought out, and frequently have unintended long term consequences. Stephen Sprunk wrote: > You have the flawed assumption that everyone who uses RFC1918 space > today will want/need ULA-C in the future. The vast majority of folks > will be fine with ULA-L (or PA) space, and the target market for ULA-C > is identical to the target market for PIv6. It will be the same number > of orgs regardless of which type of space they request, so the debate > comes down to why we want to put orgs on ULA-C space instead of just > giving them PI space. If they're truly going to use it privately, > they won't consume routing slots in the DFZ, and if they aren't they'll > be using PIv6 anyways and won't have a need for ULA-C. I agree that the ULA-C need will map to the PI need, though ULA-C may be a subset. The last line though is IPv4-thinking, in that it assumes people will only use one address range at a time. People may well use PI for their nodes that have public access, at the same time using ULA-C for the ones that don't to minimize the firewall rules. The only 'value' to ULA-C over ULA-L is the assurance to management that 'this has been registered so the risk of a required renumbering event down the road is reduced'. It really doesn't matter if human error is greater than the probability of collision in ULA-L, this is not a technical issue, it is strictly a feel-good that people are willing to pay for. The RIRs should be all over customers like this, because their demands are low and their willingness to pay is high. Leo Bicknell wrote: > - IPv6 space is not infinite. It's a 64-72 bit address space. That's > right, subnets with > 256 hosts are very uncommon today, so we've > wasted 64 bits to number 256 things. That makes the space effectively > on the long end 72 bits. This goes back to Iljitsch's comment: just because you don't see the need, don't deny others the opportunity to innovate... The original proposal for 64 bits met the design goals for IPv6 by 3 orders of magnitude, but the routing world was concerned that there would not be enough space for the hierarchy of providers, so the entire 64 bits was given to them and the debate raged about how many more bits to add for the hosts. For operational simplicity in auto-configuring hosts it was decided that EUI-64 would be the best choice because the IEEE would run out of EUI-48's within the life expectancy of IPv6. Now we find the routing world arguing about 'waste' because they are just a greedy bunch that really don't want others to have something that they think they control, even if the can't use them. To prove the point, line this up with the FUD about not being able to route /48's as PI space because there are just too many of them. If there are too many /48's, what in the world would the routing system do with more bits? This occurs in the /48-/56 discussion as well because again if there are too many /48's why do we need to make sure end sites only get /56's. This is not about 'waste', it is all about 'control'. The policy realm is dominated by routing types, and they want to make sure they have control over the use of the bit space, even when they know they couldn't possibly use it. If you really want to see waste, allocate all the bits to routing. The world will move on to some other technology long before we run out of even /48's, because this is not the be-all-end-all of protocols. If the allocations allow innovation, there will be new approaches that might even minimize the workload of the routing world. Paul_Vixie wrote: > the real problems with IPv6 are those it shares with IPv4, so let's just > call it "the real problems with IP". they've been argued forever and > go by many names. from ppml's point of view, the right name of the > biggest problem is "lack of EID/RID split". since we're using one > address for both identity and location, it actually matters whether that > address is universal or private,PI or PA, etc. as tli pointed out fairly > early on, a solution to this problem would have added a lot more to the > IP address system lifetime than adding more bits has added or will add. > so, the problem isn't novel, but general recognition of the problem would > certainly be novel. The EID/RID split is a red-herring used to confuse those that don't understand that ISP's operate private networks, and they want absolute control over their networks. That is fine, they should have control over their infrastructure. The point is that IP is an inter-network technology, something the telco world doesn't really get (and the traditional ISPs have forgotten during the assimilation). It has been argued that the reason the Internet won out over the traditional telco world is exactly due to the identity and locator being merged. This allowed a chain of organizations to have a clean-slate view of what this packet is about; where header rewriting techniques only provide the upstream organization's interpretation. We have the solution to the perceived problem of each ISP wanting to write its own interpretation of what to do with this packet. It is called MPLS. No matter what you call it, every attempt to overwrite the end-to-end semantics of the IPv6 header with local semantics is nothing more than a label operation. Since it is being done just for the local network, it doesn't belong in the inter-network header, it belongs in a lower layer that already carries local-only network semantics. The problem is not that the EID/RID are merged, it is that the destination network is trying to effect policy over network providers, and the network providers are trying to prevent them from doing that so they can control their own network. Again, I have no problem with ISPs wanting to control their own network, but they should be using the tool that was designed for that rather than breaking the merged semantics that the entire existing security model is built on. David Williamson wrote: > Uh, neither of those reasons undermines the solution others have > proposed: use PI space. You can always just not announce some part (or > all) of your space. That would make it private. So you have a printer on the same subnet as the laptop, and the laptop needs internet access while the printer does not. Do you explicitly list every device that is to be allowed/blocked in the firewall; or do you overlay two prefix ranges from the public space and try to keep straight which one has public access to make sure the printer is in the right one? It would be much simpler operationally to have a very different range for the local-only devices. ULA provides that. ULA-C provides an assurance to management that there is a human maintaining a list that says 'this space is ours so we will not have to renumber for partnerships or m&a'. Owen DeLong wrote: > Um, no. It's like saying that counterfeit money is bad and we'd rather > not create a sponsored system for printing it. The thing that distinguishes counterfeit from 'real' is who prints it. If the same organization does the printing it is all 'real', unless they intentionally create bogus records (errors happen even in real things). ULA-C has value to some organizations. If you really don't want that to be 'counterfeit' space, then take it, manage it, and make it real. Otherwise don't be surprised when addresses that are not managed by the RIRs start showing up in real networks. David Williamson wrote: > My argument, however, is that > there's no problem solved by ULA-C that can't be solved by PI space, > and the creation of ULA-C would entirely undermine the RIR-based PI > system. Exactly how does ULA-C undermine RIR-PI? RIR-PI space is managed with the expectation that it would be publicly routable if the recipient wanted to. ULA-C space would be managed with the expectation that it would never be publicly routed. As long as those are managed by the same organization there would be no cross-purpose in the allocation, and as long as being an RIR member was the prerequisite for either, then no organization would be motivated to use one for functions where the other was expected. If the RIRs choose not to manage ULA-C, there will be something created to do that, so the assurances of mixing purposes goes away and it becomes a bidding war for the cheapest registry. The fees are for membership, not address space so every RIR member should be allocated a PI & ULA-C block, even if they never use them. This would take all the FUD about misuse off the table. Edward Lewis wrote: > What I *sense* is happening here is that the RIRs are being used to > do an end-run around the IETF process. This 'sense' is based on > reading the draft (and seeing that this is along the lines of site > local), looking at the mail list archives (which lacks overwhelming > support to promote this), and the hint that the IETF is failing to > promote ULA (perhaps that is just from the choice of words). Despite what the message from the chairs says, the reason it was dropped was that RIRs perceived ULA-C was an end-run around their lack of policy on PI (really an unstated policy of anti-PI at the time). I guess it was politically nice to leave the inter-org dirty laundry out of it .... ULA-C will only ever see the light of day as PI in the routing system if the remaining RIRs refuse to create real PI. PI is required legally in some areas, and will exist despite policy for others. ULA-C will be required by management by many of those same organizations because it offers 'fat finger' protection through no-routing-entry in the public network. The RIRs need to recognize reality and create the policies that manage the space. The IETF could take up the draft and publish an RFC, but if the RIRs don't want to manage the space then an alternate registry gets set up. At that point there will be a bidding war over which registry provided the most space for the least cost and everything about the status quo will end. If the RIRs want to avoid that situation then they need to establish a policy that RIR members get PI & ULA-C space, even if they never intend to use it. Tony From bicknell at ufp.org Tue May 29 21:01:10 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 29 May 2007 21:01:10 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <1b7801c7a24e$4c0da560$e428f020$@net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <1b7801c7a24e$4c0da560$e428f020$@net> Message-ID: <20070530010110.GA90674@ussenterprise.ufp.org> In a message written on Tue, May 29, 2007 at 05:05:56PM -0700, Tony Hain wrote: > > Even if ULA central is useful, I don't think it is something the RIRs > > need to be involved in. > > To avoid the perpetual arguments about ULA-C vs. PI, it would be best if > both were handled by the same organization to avoid the additional nonsense > about an end run around the process. There is also the case that only > organizations that really care would even be asking for ULA-C, and if they > care enough they would be willing to become RIR members if need be. > Additional recurring revenue for what is essentially a one-time effort > should be enough of a reason for the RIR's to be involved. I'm not sure I've seen the argument made this way before, but to me it's a new, a good argument. Specifically "RIR's should administer ULA-C so they can help direct people to ULA-C or PI as appropriate." I think that's an accurate morph of your statement. While I'm still not sure about ULA-C, thinking about it that way makes me think that if it is implemented, the RIR's are the right place. > Now we find the routing world arguing about 'waste' because they are just a > greedy bunch that really don't want others to have something that they think > they control, even if the can't use them. To prove the point, line this up > with the FUD about not being able to route /48's as PI space because there > are just too many of them. If there are too many /48's, what in the world > would the routing system do with more bits? This occurs in the /48-/56 This is distorting a near-term problem. If in 1993 I told you that your AGS+ with 8M of ram would need to route 200,000 prefixes from 200 different BGP sessions you would have laughed me out of the room. Today we think of a 5,000,000 prefix Internet as an impossibility. No hardware could ever do that. However, 20 years on I'm not sure a 5 million route Internet will be surprising to anyone. The fact that we might not be able to route a /48 for everyone who wants PI with today's hardware, or even in 5 years time does not mean we should flush the possibility down the drain by giving those who are worth of of space today so much space there will be none left tomorrow. At the time of the AGS+, giving HP a /8 and DEC a /8 "made sense". Today having one company that doesn't even provide any Internet services directly having a /7 (15/8 and 16/8) seems absolutely absurd. At the time having them consume a single route in your AGS seemed like a great idea. Today having them consume 4 /19's (as an example) might seem like a better tradeoff, 4 routing slots in exchange for using 10 bits less of address space. The thing of it is, as we're seeing with IPv4, taking space back is really hard. Now, some people think that a 25 year lifespan for IPv6 is "doing good". I think if by allocating addresses more prudently we could make it 50 years, that's billions of future dollars and effort saved, and more important to me, perhaps avoiding the next version of this transition in my lifetime! I believe the problem when we get into these arguments though is that it seems like there two options for the pendulum, the far left and the far right. I would hope as a community we could do a better job to find the middle, but no one on either side of the argument seems interested in understanding where the middle might actually be located. "You're a big company, and you have to use Class C subnets, so you should have 65536 of them, here's a Class A." "You're a big company, you have to give out /48 subnets, so you should have 65536 of them, here's a /32." Seems like we could have at least been creative this time around and picked a different number. Why do big companies need 65536 subnets? The number must be magical. -- 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 narten at us.ibm.com Tue May 29 22:46:48 2007 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 29 May 2007 22:46:48 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: Message-ID: <200705300246.l4U2kmJ7018886@cichlid.raleigh.ibm.com> > What failed previously ... IESG can say, I only have hints, and points to > something not good in my opinion, but I don't want to talk here about > something that I don't know completely. What "failed" is that the IETF was fairly close to approving the ULA-C approach, but at one ARIN meeting, there was an uproar over the idea. The IETF then dropped the idea because it just seemed too painful to continue pushing on it at the time (there was a message sent to the IPng mailing list when this happened, and the WG agreed, but it would take some digging to find the exact message). Plus, the IETF had by then approved probalistically-unique ULAs (RFC 4193) which took off much of the pressure for ULA-C. So there was a feeling that we should just drop the ULA-C approach and see what happened. Even then it was felt that it could be resurrected, if the RFC 4193 proved to be insufficient in practice. Thomas From narten at us.ibm.com Tue May 29 22:49:38 2007 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 29 May 2007 22:49:38 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465C3FDE.7050708@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> Message-ID: <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> > sounds like a great idea for all of ipv6 allocation. what is the > difference ula or pi/pa? Here's my take. ULAs are not intended to be publically routed by ISPs. While some may attempt to get ISPs to route them, ISPs will have clear documentation saying they are not intended to be used that way, and they are free to filter them. And in fact they SHOULD be filtered. (I'd say MUST, but since that is not enforceable...) We have ULAs already. What is missing is centralized ULAs. I've had enough conversations with people that want to use ULAs - but simply aren't satisfied with probalistic uniqueness. They want something more meaningful, like a signed contract that that can pay some fee for and get some assurance that no one else is going to get that address. This sort of thing makes business people happy. People do worry about collisions and the impact that would have. ULAs are intended to be much more easy to obtain than PI space, because PI space is intended to be publically routed. PI space, on the other hand, is not useful if it is not publically routed (generally speaking). Poeple obtaining PI space are very much assuming it will be publically routed. ULA space is useful even if not publically routed (and is intended for uses that do not require public routability). E.g., it can be used to number infrastructure devices, with assurance those addresses will not need to change the way public addresses might. Is ULA space the same as PI? Only if you want to give everybody and their brother PI space and don't care about what that does to the routing tables. I don't believe we can (or should) do that. And keep in mind, in IPv6 devices can have multiple addresses simultaneously. So it is quite possible to have ULA-C addresses in addition to public addresses. So having ULA-C addresses does not imply that those addresses have to be used for communicating with off-site destinations. Thomas From sleibrand at internap.com Wed May 30 00:52:03 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 29 May 2007 21:52:03 -0700 Subject: [ppml] A registered ULA policy proposal outline In-Reply-To: <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> Message-ID: <465D02F3.2040704@internap.com> So after spending way too much time reading way too many messages about ULA-central, I think an actual policy proposal is needed to blow away the smoke and see whether the wood is actually dry enough to be useful for cooking marshmallows. My reading of the PPML discussion to date leads me to the following conclusions: * There are a number of organizations who would prefer to be able to acquire some form of registered unique local IPv6 addresses. * There are a number of arguments against a single central ULA registry centering around the desire to avoid "registry shopping." * For organizations in the ARIN region, there is consensus that organizations desiring to announce directly assigned space to transit providers should acquire space under ARIN's PI policy. * There are a number of organizations in the ARIN region who wish to acquire some form of registered ULAs for private, not-publicly-routed use (in addition to either PI or PA space). * Some people participating in the ARIN public policy process are uncomfortable asking ARIN to create a ULA registry without an RFC defining their various aspects, such as how registered ULAs should be allocated from IANA to the RIRs, how registered ULAs are intended to be used, etc. * Some people participating in the IETF process are (or have been) uncomfortable moving forward the existing ULA-central draft due to a perception of opposition at the RIRs. It is unclear to me whether this is largely historical (from before ARIN passed its PI policy) or whether it persists. If people who believe registered ULAs would meet a currently unmet need would like to move toward an ARIN ULA registry, I believe they should draft a policy something along the following lines, and then work to determine whether the particulars of the policy, and the idea as a whole, enjoy support among interested participants of the public policy process. (As before, I think a poll along the lines of Andrew Dul's 2005-1 IPv6 PI poll would be helpful.) So without further ado, here's a draft outline of a possible registered ULA policy proposal: * ARIN representatives should work with the IETF to help adopt an RFC defining the particulars of a registration function for Unique Local IPv6 Addresses (ULAs). A suitable RFC might define a range of IPv6 space for IANA to allocate to participating RIRs, which would then assign blocks to organizations. The RFC might also recommend that ULAs SHOULD NOT be announced to or accepted by Internet transit providers. * Upon adoption of such an RFC, ARIN should create a registry to assign registered Unique Local IPv6 Addresses (registered ULAs). The registry should assign a unique netblock to each registrant, should track and provide public information about such registrations through directory services like whois, and should provide reverse DNS delegation (ip6.arpa). * Upon creation of a registered ULA registry, ARIN should begin accepting applications for registered ULA netblocks. Such netblocks should be assigned to any organization in the ARIN region requiring registered ULAs for internal addressing purposes. ARIN should help ensure applicants are aware that ULAs are not intended to be routable (referencing the RFC), and should direct applicants to apply under the IPv6 PI policy or acquire space from their ISP(s) if they desire routable space. As I have no personal interest in registered ULAs (just a general interest in the good of the Internet community, and a desire to improve the signal to noise ratio of my ppml folder), I'm probably not the right person to actually write a registered ULA policy proposal. If there's support for the idea, I hope someone with an interested in registered ULAs can take the outline above, and the feedback it will inevitably generate, and draft a policy proposal. -Scott From jordi.palet at consulintel.es Wed May 30 03:48:38 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 30 May 2007 09:48:38 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <200705300246.l4U2kmJ7018886@cichlid.raleigh.ibm.com> Message-ID: Well, now that you say it, I heard that there was also a very direct pressure on top of the IESG. If that was the case, it was nasty and the IESG did wrong allowing an "out-of-band" interference in the IETF process, because all that should have gone to the WG. Regards, Jordi > De: Thomas Narten > Responder a: > Fecha: Tue, 29 May 2007 22:46:48 -0400 > Para: > CC: > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > >> What failed previously ... IESG can say, I only have hints, and points to >> something not good in my opinion, but I don't want to talk here about >> something that I don't know completely. > > What "failed" is that the IETF was fairly close to approving the ULA-C > approach, but at one ARIN meeting, there was an uproar over the > idea. The IETF then dropped the idea because it just seemed too > painful to continue pushing on it at the time (there was a message > sent to the IPng mailing list when this happened, and the WG agreed, > but it would take some digging to find the exact message). Plus, the > IETF had by then approved probalistically-unique ULAs (RFC 4193) which > took off much of the pressure for ULA-C. So there was a feeling that > we should just drop the ULA-C approach and see what happened. Even > then it was felt that it could be resurrected, if the RFC 4193 proved > to be insufficient in practice. > > Thomas ********************************************** 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 iljitsch at muada.com Wed May 30 04:20:48 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 30 May 2007 10:20:48 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529172557.GS5379@shell01.corp.tellme.com> References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: <5A2786C0-4D5D-48B3-8C61-C54CD421A82E@muada.com> On 29-mei-2007, at 19:25, David Williamson wrote: > Uh, neither of those reasons undermines the solution others have > proposed: use PI space. Well, give me a couple of PI blocks and I'll think about it. Did I mention that I'm in the RIPE region but not a RIPE member/LIR? And that my IPv4 space is a /29 plus a /32? From heldal at eml.cc Wed May 30 04:19:48 2007 From: heldal at eml.cc (Per Heldal) Date: Wed, 30 May 2007 10:19:48 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529172557.GS5379@shell01.corp.tellme.com> References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: <1180513188.25300.24.camel@localhost.localdomain> On Tue, 2007-05-29 at 10:25 -0700, David Williamson wrote: > Uh, neither of those reasons undermines the solution others have > proposed: use PI space. You can always just not announce some part (or > all) of your space. That would make it private. Until there's a magic solution for scalable IDR you'll hit the filter-wall. For ARIN's PI-block (/48 as defined by ARIN), expect networks to filter anything that is more specific. Hence you won't be able to keep a chunk "private" by making it "invisible" to the outside world. > ULA-C sounds to me like a request to the guys who spin silicon to help > people keep from screwing up their router configs. If someone can't > manage to filter their BGP such that they keep some (or all) of their > space private, I don't see why Cisco, Juniper, et al., need to do > that for them. ULA-C is a questionable workaround for the IT-industry's failure to solve basic problems. E.g; why, in 2007, is renumbering even an issue anymore? It shouldn't be a problem when changing upstream provider, nor should it be an issue when different private networks are joined. //per From iljitsch at muada.com Wed May 30 04:27:25 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 30 May 2007 10:27:25 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: <37A78B44-458F-45DF-B986-4E24B48A6B69@muada.com> On 29-mei-2007, at 19:09, Scott Nelson wrote: >>> Advantages of ULA-C (even to those who claim there are some): >>> Virtually none. >> I'm sure you don't mind the plane renumbering in flight when it >> switches from one satellite connection to the next. Myself, I'd like >> to see the flight systems to have stable addressing regardless of the >> orientation of the satellite antennas. > I'm not seeing something here. Wouldn't the plane have an IP > address given to it from the airline? If the airline needs to > renumber, wouldn't they would do it in stages -- as planes land? If you number the planes from the airline's address space, you need to keep rerouting those address blocks for the planes continuously as the plane flies around. It's really hard to make that work well, and the airline probably needs some kind of world-wide private network to do it. It makes much more sense to give the parts of the plane that need connectivity addresses that are tied to the connection they happen to have at any point in time. I.e., when it's in the air the passengers can email through a satellite link, when it's on the ground the service people can access the plane's systems for maintenance. But you really want the different systems in the plane to be able to talk to each other regardless of what external connectivity there is and regardless of any addressing such connectivity brings with it. From heldal at eml.cc Wed May 30 04:33:49 2007 From: heldal at eml.cc (Per Heldal) Date: Wed, 30 May 2007 10:33:49 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529190802.GZ5379@shell01.corp.tellme.com> References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> <20070529190802.GZ5379@shell01.corp.tellme.com> Message-ID: <1180514029.25300.34.camel@localhost.localdomain> On Tue, 2007-05-29 at 12:08 -0700, David Williamson wrote: > I wasn't going to post again today to this list, but I cannot let > blatantly incorrect statements go by. PI is not hard to get, although > your experience may vary by region. My org holds a PI /48, and it > took me 2 days of duration and ten minutes of effort to receive it. > That's nearly trivial, in my book. If you want to endorse PI for "private" use please also consider that it leaves blocks wide open to abuse. Separate ULA-C space can easily be filtered, but how do you easily prevent hijacking of unannounced PI-prefixes should such private blocks become as commonplace as rfc1918-space? //per From michael.dillon at bt.com Wed May 30 05:21:35 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 30 May 2007 10:21:35 +0100 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: Message-ID: > That's broken. As it has been stated in previous messages > some days ago, RIR communities can do whatever they want, > especially if IETF fails. That may be true but since the IETF is not failing, there is no reason for the RIRs to take over any IETF functions. > I'm doing IETF work, but it is > clear that some times, for whatever reasons is too slow, or > even fails. This community has the right to bypass that if required. What community? So far I see only you suggesting that the RIRs should usurp the IETF role in defining Internet numbers. > And one more demonstration that this is broken: All the RIRs > did 4-byte-ASN policies when no RFCs where available. As you > can see the RIR system is still working. Jordi, you are twisting the truth. When the RIRs passed the 4-byte ASN policies, there were already Internet drafts working their way through the IETF process. 4-byte ASN work was part of the charter of the IETF's IDR working group. According to the IDR records here http://www3.ietf.org/proceedings/05nov/idr.html They had a goal to submit an RFC candidate document to the IESG in October 2005 which was more than a year before ARIN passed its 4-byte ASN policy. This is an example of the RIRs working in concert with the IETF. What you are proposing is for the RIRs to completely bypass the IETF process entirely. > So yes, I will much prefer to have an RFC, and this is the > way we are going, but nothing precludes to go in parallel, as > it has been done in the 4-byte-ASN, and probably some other > times I guess. Your guess is not good enough. In fact, even if you manage to get an RIR to pass some sort of ULA-C policy, it will not be good enough for most companies who want a centrally registered address block. These companies want some security of ownership in those addresses. They want strong assurances that their registered allocation will stay with them for the life of the company or the life of IPv6 whichever comes first. If ULA-C comes about through the dubious process that you propose, then there is no guarantee that the RIRs won't revoke ULA-C 6 months later. I would recommend that anyone needing the guarantee of uniqueness from a central registry should apply for PI address blocks. And if your local RIR does not offer PI IPv6 blocks, then work to get a policy passed to do this, such as was done in the ARIN region. > And, in the worst case, if the IETF fails again on this (I'm > sure will not be the case this time), we could always go for > a global policy to instruct IANA to delegate that resource to > the RIRs. > > Regards, > Jordi > > > > > > De: > > Responder a: > > Fecha: Tue, 29 May 2007 22:13:47 +0100 > > Para: , > > Conversaci?n: [ppml] [address-policy-wg] Those pesky ULAs again > > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > > >> The policies for ULA-C are likely to be different from the > policies > >> for PI. > > > > ULA-C doesn't exist. There is not even a current Internet draft to > > define what the acronym stands for. If any RIRs create a policy on > > that basis, then it will be the beginning of the end of the > RIR system. > > > > The RIRs are supposed to be stewards, prudently managing a shared > > resource. > > > > --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. > > > > _______________________________________________ > 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 Wed May 30 05:32:26 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 30 May 2007 10:32:26 +0100 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529222033.GA83891@ussenterprise.ufp.org> References: <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no><007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com><465BA1B9.1060003@psg.com><031b01c7a1ca$64904270$dc128953@kantoor.computel.nl><465BE3AB.8040305@psg.com><20070529135031.GA57185@ussenterprise.ufp.org><12093.1180450716@sa.vix.com><20070529160116.GN5379@shell01.corp.tellme.com><465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <20070529222033.GA83891@ussenterprise.ufp.org> Message-ID: > Conversely, it would be rather trivial to add random address > assignment to IPv4. ICMP router solicitation, auto configure > into the subnet, randomly assign a IP, look for a collision. > AppleTalk did it 15 years ago. Worked good for small > deployments. Would be fun to write the code and check it > into several distros.... If you don't, then somebody else will. Remember when I said that one strategy to mitigate IPv4 exhaustion is to share addresses between regions, i.e. an American small business could use the same allocation as a Korean small business and a French small business. It is unlikely that they would ever need to communicate much outside their regions. And the RIRs could step in an manage such allocations to prevent too many people using the same address and to ensure that the users understand the limitations of such shared addresses. However, if your devices could pick a random IPv4 address, check whether or not it is Internet reachable, then check routability to some major sites, and then decide to use it... Note that this would also solve the RFC 1918 exhaustion problem that many large enterprises are struggling with. In general, I'm in favor of making all possible mitigation tactics available and letting the market decide. Your random allocation and test tactic. The class E address tactic. The expansion of RFC1918 address space tactic. And others yet to be though of. --Michael Dillon From narten at us.ibm.com Wed May 30 08:57:56 2007 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 30 May 2007 08:57:56 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: Message-ID: <200705301258.l4UCvuWP011461@cichlid.raleigh.ibm.com> Jordi, > Well, now that you say it, I heard that there was also a very direct > pressure on top of the IESG. If that was the case, it was nasty and the IESG > did wrong allowing an "out-of-band" interference in the IETF process, > because all that should have gone to the WG. Please don't post/further propagate rumors, unless you have real evidence to back things up. There was no interference. I'd also bet money that the IETF would not approve something like ULAs if the RIRs are in serious opposition (And I, wearing my IETF hat, would oppose such an action). It was a mutual decision to drop ULA-C. Niether ARIN nor the IETF was interested in pushing it forward after the infamous ARIN meeting where ULA-Cs were last discussed. The IPv6 WG agreed to this action (go check the archive). Given that, your words above are completely inappropriate and unhelpful. And I believe I was still AD at the time this all happened. I was also the one up on stage at the ARIN meeting defending ULA-Cs when the rotten tomatoes were thrown. I remember that meeting well. :-) Thomas From stephen at sprunk.org Wed May 30 10:20:59 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 30 May 2007 09:20:59 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again References: Message-ID: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> Thus spake "JORDI PALET MARTINEZ" > Agree, in ARIN region is not difficult to get, but in other two regions > (LACNIC and RIPE NCC) is still impossible. > > However more difference to point to is that using PI for a function > such as the one covered by ULA-Central is wasting space. How is using a PI /48 any more or less wasteful than a ULA-C /48? If anything, there is less ULA space (currently /7) available than PI space (currently /3) so we should be more concerned about waste in ULA land. Creating a new type of address space for "private" use just because some companies are too lazy to figure out how to configure their firewalls (which don't even exist yet) is not good engineering. 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 tme at multicasttech.com Wed May 30 10:48:16 2007 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 30 May 2007 10:48:16 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <1180514029.25300.34.camel@localhost.localdomain> References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> <20070529190802.GZ5379@shell01.corp.tellme.com> <1180514029.25300.34.camel@localhost.localdomain> Message-ID: On May 30, 2007, at 4:33 AM, Per Heldal wrote: > On Tue, 2007-05-29 at 12:08 -0700, David Williamson wrote: >> I wasn't going to post again today to this list, but I cannot let >> blatantly incorrect statements go by. PI is not hard to get, >> although >> your experience may vary by region. My org holds a PI /48, and it >> took me 2 days of duration and ten minutes of effort to receive it. >> That's nearly trivial, in my book. > > If you want to endorse PI for "private" use please also consider > that it > leaves blocks wide open to abuse. Separate ULA-C space can easily be > filtered, but how do you easily prevent hijacking of unannounced > PI-prefixes should such private blocks become as commonplace as > rfc1918-space? How do you prevent it now, in IPv4 ? (I know several companies with addressable blocks for internal use, and so I suspect that this is not that rare.) Regards Marshall > > //per > > _______________________________________________ > 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 marla.azinger at frontiercorp.com Wed May 30 11:28:08 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 30 May 2007 11:28:08 -0400 Subject: [ppml] A registered ULA policy proposal outline Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F8F4@nyrofcs2ke2k01.corp.pvt> Hello I have been reading all the ULA emails and decided some of you might be interested to know the following: A small group of people (including Jason Schiller, Thomas Narten, Marla Azinger, Bob Hinden, Geoff Huston) have been discussing this very subject and what actions we need to pursue in order to evolve from circular conversations. Here is what action we are taking: Bob Hinden is going to revise the expired Centralized ULA Internet Draft, updating it based on input received from various forum discussions. We plan to submit this draft to the v6ops WG in time for the Chicago IETF with a goal of having it published as an RFC. Part of the new wording will be to clarify the ULA ID properties needed to make it work but leave out the details of how to achieve this to the RIR's. So yes, this document will "request" RIR involvment. And if/when approved, the document would task IANA with disseminating the ULA Addresses to the RIR's for assignment. We believe significant changes have occured in the last two years that make ULA a reasonable and acceptable requirement and that to make it work it needs the cooperation of IANA, IETF and RIR's. We are working to bridge this gap with a revised proposal that will (hopefully!) get us out of the circular discussions. Thank you for your time Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Scott Leibrand Sent: Tuesday, May 29, 2007 9:52 PM To: ppml at arin.net Subject: [ppml] A registered ULA policy proposal outline So after spending way too much time reading way too many messages about ULA-central, I think an actual policy proposal is needed to blow away the smoke and see whether the wood is actually dry enough to be useful for cooking marshmallows. My reading of the PPML discussion to date leads me to the following conclusions: * There are a number of organizations who would prefer to be able to acquire some form of registered unique local IPv6 addresses. * There are a number of arguments against a single central ULA registry centering around the desire to avoid "registry shopping." * For organizations in the ARIN region, there is consensus that organizations desiring to announce directly assigned space to transit providers should acquire space under ARIN's PI policy. * There are a number of organizations in the ARIN region who wish to acquire some form of registered ULAs for private, not-publicly-routed use (in addition to either PI or PA space). * Some people participating in the ARIN public policy process are uncomfortable asking ARIN to create a ULA registry without an RFC defining their various aspects, such as how registered ULAs should be allocated from IANA to the RIRs, how registered ULAs are intended to be used, etc. * Some people participating in the IETF process are (or have been) uncomfortable moving forward the existing ULA-central draft due to a perception of opposition at the RIRs. It is unclear to me whether this is largely historical (from before ARIN passed its PI policy) or whether it persists. If people who believe registered ULAs would meet a currently unmet need would like to move toward an ARIN ULA registry, I believe they should draft a policy something along the following lines, and then work to determine whether the particulars of the policy, and the idea as a whole, enjoy support among interested participants of the public policy process. (As before, I think a poll along the lines of Andrew Dul's 2005-1 IPv6 PI poll would be helpful.) So without further ado, here's a draft outline of a possible registered ULA policy proposal: * ARIN representatives should work with the IETF to help adopt an RFC defining the particulars of a registration function for Unique Local IPv6 Addresses (ULAs). A suitable RFC might define a range of IPv6 space for IANA to allocate to participating RIRs, which would then assign blocks to organizations. The RFC might also recommend that ULAs SHOULD NOT be announced to or accepted by Internet transit providers. * Upon adoption of such an RFC, ARIN should create a registry to assign registered Unique Local IPv6 Addresses (registered ULAs). The registry should assign a unique netblock to each registrant, should track and provide public information about such registrations through directory services like whois, and should provide reverse DNS delegation (ip6.arpa). * Upon creation of a registered ULA registry, ARIN should begin accepting applications for registered ULA netblocks. Such netblocks should be assigned to any organization in the ARIN region requiring registered ULAs for internal addressing purposes. ARIN should help ensure applicants are aware that ULAs are not intended to be routable (referencing the RFC), and should direct applicants to apply under the IPv6 PI policy or acquire space from their ISP(s) if they desire routable space. As I have no personal interest in registered ULAs (just a general interest in the good of the Internet community, and a desire to improve the signal to noise ratio of my ppml folder), I'm probably not the right person to actually write a registered ULA policy proposal. If there's support for the idea, I hope someone with an interested in registered ULAs can take the outline above, and the feedback it will inevitably generate, and draft a policy proposal. -Scott _______________________________________________ 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 narten at us.ibm.com Wed May 30 11:03:52 2007 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 30 May 2007 11:03:52 -0400 Subject: [ppml] 5M prefixes in the core [was: Re: [address-policy-wg] Those pesky ULAs again ] In-Reply-To: <20070530010110.GA90674@ussenterprise.ufp.org> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <1b7801c7a24e$4c0da560$e428f020$@net> <20070530010110.GA90674@ussenterprise.ufp.org> Message-ID: <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> Leo Bicknell writes: > Today we think of a 5,000,000 prefix Internet as an impossibility. > No hardware could ever do that. However, 20 years on I'm not sure > a 5 million route Internet will be surprising to anyone. Who is the "we" you refer to above/ Actually, quite a few people are worried that a 5M prefix Internet is a possibility. There are also debates (i.e., no consensus) that when that happens, routers will actually be able to cope with the load in practice. I.e., see draft-iab-raws-report-02.txt and the efforts going on in the IETF, e.g.: http://www1.ietf.org/mail-archive/web/int-area/current/msg00763.html http://www1.ietf.org/mail-archive/web/int-area/current/msg00783.html Just to give one data point, router vendors are saying that today, they have routers that can support 1M routers. Operators (at least some of them), are skeptical, because that hasn't been proven operationaly in the field. So, there is at least some uncertainty as to what can be supported in practice. > The thing of it is, as we're seeing with IPv4, taking space back > is really hard. Now, some people think that a 25 year lifespan for > IPv6 is "doing good". I think if by allocating addresses more > prudently we could make it 50 years, that's billions of future > dollars and effort saved, and more important to me, perhaps avoiding > the next version of this transition in my lifetime! Glad to see you are thinking of an lifespan of more than just a few years. Indeed, I think many are thinking of even longer time frames. For example, policy proposal "2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement" (http://www.arin.net/policy/proposals/2005_8.html), which ARIN has adopted, was motivated very much by looking at time lines 100 years and longer... Thomas From Ed.Lewis at neustar.biz Wed May 30 09:53:43 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 30 May 2007 09:53:43 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <200705300246.l4U2kmJ7018886@cichlid.raleigh.ibm.com> References: <200705300246.l4U2kmJ7018886@cichlid.raleigh.ibm.com> Message-ID: At 22:46 -0400 5/29/07, Thomas Narten wrote: >What "failed" is that the IETF was fairly close to approving the ULA-C >approach, but at one ARIN meeting, there was an uproar over the >idea. Besides reading Thomas' message, I asked the editors of the document why it had fallen into an expired state. The reason given was similar, that it was a technology that seemed to have negative implications for the policy space, i.e., it was something the IETF worked on that caused a problem for RIR policy, specifically within ARIN. Now that there is a policy to allocate IPv6 provider independent space in ARIN, and as Thomas said alternatives to ULA-C have failed to fill the gap, a new version of the ULA-C document is in production. I'm posting this because I cringe when there are accusations of an organization "failing" or stonewalling something. Also, from the lack of documentation on this topic, I was wary of there being some underlying technical glitch that had sprung up and cause the document to decay. Apparently the hold up was the IETF listening to the feedback of the RIRs. The objections then seem not to hold anymore. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From bmanning at karoshi.com Wed May 30 12:01:32 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Wed, 30 May 2007 16:01:32 +0000 Subject: [ppml] 5M prefixes in the core [was: Re: [address-policy-wg] Those pesky ULAs again ] In-Reply-To: <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <1b7801c7a24e$4c0da560$e428f020$@net> <20070530010110.GA90674@ussenterprise.ufp.org> <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> Message-ID: <20070530160132.GA5364@vacation.karoshi.com.> On Wed, May 30, 2007 at 11:03:52AM -0400, Thomas Narten wrote: > Leo Bicknell writes: > > > Today we think of a 5,000,000 prefix Internet as an impossibility. > > No hardware could ever do that. However, 20 years on I'm not sure > > a 5 million route Internet will be surprising to anyone. > > Who is the "we" you refer to above/ > > Actually, quite a few people are worried that a 5M prefix Internet is > a possibility. There are also debates (i.e., no consensus) that when > that happens, routers will actually be able to cope with the load in > practice. > hum... given that w/ a /32 "boundary" - there exists the possibility of 2x32 routing table entries... clearly the /32 boundary is not to preserve routing table slots. if one is seriously considering a 1-5m entry routing table then it becomes important to (proxy) aggregate to the /8 or /9 level to keep within the 1 to 5m entries. --bill From Paul_Vixie at isc.org Wed May 30 12:22:09 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Wed, 30 May 2007 16:22:09 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Wed, 30 May 2007 09:20:59 EST." <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> Message-ID: <78600.1180542129@sa.vix.com> aside from the difficulties pointed out during this thread regarding enforcement of ULA terms vs. PI terms, there are two other things that prevent me from thinking well of ULA. first, ARIN does not currently consider routability when allocating address space. non-routable space comes from ietf/iana, not the RIRs. so, for ARIN to start allocating nonroutable space is a big change. we would have to define "routable", we could face implied liability for routability on "normal address space" (even if we continue to disclaim it in the NRPM as we do now), and we would then walk the slippery slope of the changing definition "largest" with respect to breidbart's maxim: >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart second, even with the rampant EUI64 wastage of the bottom 64 bits of the IPv6 address space, there's still a lot of space, and it's not hard to get. it's perfectly reasonable for all addresses to be unique even if some are never expected to be "routed" or are only "privately routed" or whatever. so while i think that ietf/iana ought to allocate a "private" block of space for IPv6 since a lot of the world loves their IPv4 NAT and wants to be able to do the same thing with IPv6, one block ought to be enough. (heck, maybe the old site-local prefix is still available.) From bicknell at ufp.org Wed May 30 12:40:39 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 30 May 2007 12:40:39 -0400 Subject: [ppml] 5M prefixes in the core [was: Re: [address-policy-wg] Those pesky ULAs again ] In-Reply-To: <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <1b7801c7a24e$4c0da560$e428f020$@net> <20070530010110.GA90674@ussenterprise.ufp.org> <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> Message-ID: <20070530164039.GA37412@ussenterprise.ufp.org> In a message written on Wed, May 30, 2007 at 11:03:52AM -0400, Thomas Narten wrote: > > Today we think of a 5,000,000 prefix Internet as an impossibility. > > No hardware could ever do that. However, 20 years on I'm not sure > > a 5 million route Internet will be surprising to anyone. > > Who is the "we" you refer to above/ A number of operators keep standing up at ARIN meetings and telling us that if the IPv6 Internet had the same number of routes as the IPv4 Internet (e.g. ~200k) that the world would end. While I'm making a bit of an assumption, if we can't support that rate, how would we ever get to 5M in 20 years? > Actually, quite a few people are worried that a 5M prefix Internet is > a possibility. There are also debates (i.e., no consensus) that when > that happens, routers will actually be able to cope with the load in > practice. I have no worry. 1 order of magnitude growth in 20 years is way below the rate computing power and bandwidth are increasing. Heck, I think a 50 million entry table in 20 years is well within the advances in hardware we will see in that time. > Glad to see you are thinking of an lifespan of more than just a few > years. Indeed, I think many are thinking of even longer time frames. Which is excellent. I think a 50-100 year planning window may be pushing the limits of what we can achieve, but I'm all for trying! -- 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 randy at psg.com Wed May 30 12:42:32 2007 From: randy at psg.com (Randy Bush) Date: Wed, 30 May 2007 09:42:32 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> Message-ID: <465DA978.3020502@psg.com> thomas, that's all nice. but please explain why this is technically any different and better than pi space. i keep remembering It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful. -- Jon Postel From heldal at eml.cc Wed May 30 12:43:44 2007 From: heldal at eml.cc (Per Heldal) Date: Wed, 30 May 2007 18:43:44 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> <20070529190802.GZ5379@shell01.corp.tellme.com> <1180514029.25300.34.camel@localhost.localdomain> Message-ID: <1180543424.25300.57.camel@localhost.localdomain> On Wed, 2007-05-30 at 10:48 -0400, Marshall Eubanks wrote: > On May 30, 2007, at 4:33 AM, Per Heldal wrote: > > > If you want to endorse PI for "private" use please also consider > > that it > > leaves blocks wide open to abuse. Separate ULA-C space can easily be > > filtered, but how do you easily prevent hijacking of unannounced > > PI-prefixes should such private blocks become as commonplace as > > rfc1918-space? > > How do you prevent it now, in IPv4 ? I filter private addresses ;) (rfc1918). > (I know several companies with > addressable blocks for > internal use, and so I suspect that this is not that rare.) I expect those relatively few with "hidden" V4 PI to be elegible for V6 PI and that they will continue a similar practise with V6. My concern is directed at those who promote unannounced public V6 blocks as a mass-replacement for rfc1918 when efforts imho are better spent on solutions to eliminate the use of NAT and private space. Btw, holding back part of a PI block is also going to create problems. >From a transit-provider perspective I find it reasonable to filter anything smaller than RIR-allocated blocks . I.e. anything longer than a /48 from PI-land is filtered. A couple extra bits may be accepted if the as-path-length is 2 or less (for TE purposes). Similar goes for PA-land. Where does that leave a /48 split split up to keep parts of it "secret"? //per From randy at psg.com Wed May 30 12:49:08 2007 From: randy at psg.com (Randy Bush) Date: Wed, 30 May 2007 09:49:08 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> Message-ID: <465DAB04.30607@psg.com> > Creating a new type of address space for "private" use just because some > companies are too lazy to figure out how to configure their firewalls (which > don't even exist yet) is not good engineering. "Some people want it." and i want cash to fall from the sky. if we do everything anybody wants, we will have even less reliable code, more net breakage, ... randy From kkargel at polartel.com Wed May 30 14:43:19 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 30 May 2007 13:43:19 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706F72@mail> I will agree with this.. though I might have phrased it differently. Rather than mandate how organizations must use portions of their allocations, why not just let the whole thing be publicly routable? Then if an organization decides to use part of their allocation for private routing they can choose a block and quantity appropriate for their needs. Just as today we block private addresses at the network edge, we can continue to do so for IPv6. IPv6 is bigger, but it's not magic.. I have access lists in place on my routers to prevent private IP routing and IP spoofing.. I assume (yeah, I know) that most responsible sysadmin's do the same. I really don't understand the controversy over or need for ULA-C. Feel free to honestly educate me. I like feeling educated. Kevin :$s/worry/happy/g > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Stephen Sprunk > Sent: Wednesday, May 30, 2007 9:21 AM > To: jordi.palet at consulintel.es; ARIN PPML; address-policy-wg at ripe.net > Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > Thus spake "JORDI PALET MARTINEZ" > > Agree, in ARIN region is not difficult to get, but in other two > > regions (LACNIC and RIPE NCC) is still impossible. > > > > However more difference to point to is that using PI for a function > > such as the one covered by ULA-Central is wasting space. > > How is using a PI /48 any more or less wasteful than a ULA-C > /48? If anything, there is less ULA space (currently /7) > available than PI space (currently /3) so we should be more > concerned about waste in ULA land. > > Creating a new type of address space for "private" use just > because some companies are too lazy to figure out how to > configure their firewalls (which don't even exist yet) is not > good engineering. > > 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 jmorrison at bogomips.com Wed May 30 15:56:15 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Wed, 30 May 2007 12:56:15 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <30761.1180458872@sa.vix.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> Message-ID: <465DD6DF.10701@bogomips.com> I'm curious about the opposition to EUI64. The process for numbering interfaces seems to have things in common with other protocols like IPX and Appletalk and a lot like the way IS-IS (of IPv4) is configured on routers, or how ES-IS would work with hosts. Maybe it's no coincidence, since Deering was (is?) working for a router vendor at the time IPv6 was designed. Maybe everyone was just too excited about plug-n-play hype back in 1995, and it seemed like a good idea to make IPv6 more dynamic, or maybe we're also so ingrained with IPv4 that we don't think about other approaches. It seems pretty straight-forward to configure a network prefix (/48 or whatever), which may be overloaded into an area identifier - for OSPFv6, IS-IS etc, and a unique /128 host identifier to a box, whether it's a router or a host. You've mentioned the split between EID/RID, and I don't know that that's *not* possible with IPv6 - I would think that v6 flow labels, header stacking and/or OSPF opaque LSAs and/or MPLS could all work here to keep routing scalable. Some consensus I got out of reading the IETF 68 was that there's no need for panic about routing in the short term, and on the other hand there's no clear solution long term - in other words the technology is still evolving. If it's still evolving now, I don't know how it could have been designed any better in 1995 - and IPv6 did go from 64 bits to 128 bits during design and added other hooks to help it evolve. Since IPv6 had to be a real world protocol, it also had to make some tradeoffs so it could be implemented in real (1995) routers, while keeping the door open for the future. Taking a guess here, I'm wondering if what you're thinking of is how to work E.164 or variable length NSAP addresses + Bind into IPv6 routing. EUI64: I know stateless auto-config isn't for routers, but that doesn't mean some protocol like it couldn't be used to bring up router interfaces betwewen the same OSPF/IS-IS area. There's often no point to having an IP address on an interface, when a link local or unnumbered address would do. Other protocols don't even use them explicitly. For some (imaginary) router you would simply have: interface loopback 0 ipv6 address 1234:5678::1/128 ! real world address of router or host ipv6 router ospf 1 prefix 1234:5678::/48 area 0 prefix-length 64 interface ethernet 0 ipv6 address eui-64 ipv6 enable ipv6 ospf 1 area 0 ! inteface ethernet 1 ipv6 address eui-64 ipv6 enable ipv6 ospf 1 area 0 ! Nowadays, hosts often have multiple, dynamic interfaces, so it would be nice to have a single host identifier, and let eui64 and icmp router solicitation or other dynamic protocols figure out the routing. Paul_Vixie at isc.org wrote: >> You're always going to be looking at a sparse /64, you've got >> 18446744073709551616 addresses. But you need it if you want to do eui64. >> > > sadly, eui64 is in the standard, and it would take a flag day to remove it. > so while i expect folks to switch from stateless address autoconfiguration > to DHCPv6 to get some auditing and to be able to set config knobs like name > server lists and so on, i believe that everybody will always use /64's for > LANs, since some embedded devices will always demand EUI64. so there's no > way to get the address space back, and IPv6 is as leo said, effectively the > same size as a 72 bit address space. > > (note well, there was an urban legend about the /64 boundary being present > in silicon on some switch or router, but in my own testing, every C and J > router i laid hands on was able to work with /96 or /120 netmasks on > connected LAN interfaces, forward to them without using more CPU time than > a connected /64, receive routes, and advertise routes. so at the moment, > "/64 is hardwired into router silicon" is just an urban legend to me. if > you want to argue this point, plz provide session traces and rev levels.) > _______________________________________________ > 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_Vixie at isc.org Wed May 30 16:27:56 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Wed, 30 May 2007 20:27:56 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Wed, 30 May 2007 12:56:15 MST." <465DD6DF.10701@bogomips.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> Message-ID: <3935.1180556876@sa.vix.com> > I'm curious about the opposition to EUI64. i want to know when a host comes onto my network. i want to have a chance to set a particular address for it. i want to be able to do an RFC2136 DNS Dynamic Update to set the AAAA and/or PTR RR. i want to be able to tell it what the local name servers are. and i want to be able to use non-sparse addressing, such as a /112 (65536 possible hosts) rather than a /64 (which is 18446744073709551615 possible hosts) per subnet. > Maybe everyone was just too excited about plug-n-play hype back in 1995, > and it seemed like a good idea to make IPv6 more dynamic, or maybe we're > also so ingrained with IPv4 that we don't think about other approaches. you're on the right track. people who i trusted to know what the IETF was and how it worked, told me in 1995 that IPv6 had "rapid renumbering" as one of its fundamental design requirements. the idea was to be able to add and delete prefixes from a LAN as an enterprise added and deleted transit providers. so, lightweight multihoming would be a side effect of rapid renumbering. subnets and hosts would have more than one prefix, and each prefix could have its own exit gateway (or share one). none of that happened. so the entire dynamic architecture that EUI64 was supposed to be part of hasn't happened. but unlike 8+8 and A6/DNAME, the IETF hasn't abolished or deprecated EUI64 (yet?). so we're doing DHCPv6 and letting the market sort out which approach is better. > You've mentioned the split between EID/RID, and I don't know that that's > *not* possible with IPv6 - I would think that v6 flow labels, header > stacking and/or OSPF opaque LSAs and/or MPLS could all work here to keep > routing scalable. i hope i didn't say it wasn't possible. i said the lack of an EID/RID split was IPv4's major problem, and IPv6 either did nothing to solve it, or made it worse, or made it harder to solve, or perhaps all three. v6 flow labels were put in to make it possible to renumber a TCP6 endpoint without teardown and re-setup of sessions. anybody got that working yet? header stacking will probably go the way of RH0 if it hasn't already, but maybe there's hope -- is there an RFC that shows how this would work for mobile IP without requiring that i tunnel the traffic in still-open TCP sessions through the gateway i was nearest to when i opened the session? i guess i'm insufficiently imaginative since i can't think of how MPLS or OSPF can be used to scale a global (exterior) internet routing system. > Some consensus I got out of reading the IETF 68 was that there's no need for > panic about routing in the short term, and on the other hand there's no > clear solution long term - in other words the technology is still evolving. :-). In other words, it's like greenhouse gas, let the grandkids work it out, we'll just continue to grow the current system incrementally so that when the solution comes it can have a lot more of our processed output to deal with. > Taking a guess here, I'm wondering if what you're thinking of is how to > work E.164 or variable length NSAP addresses + Bind into IPv6 routing. i wanted to use domain names as permanent identifiers and have network-wire addresses be as irrelevant and ephemeral as IEEE 802. i wanted to pay a setup and in-flight renumberability complexity tax on every flow, in order to avoid entrenchment and inertia in the topology. there was talk at one time of an ICMP6 message for "tell me your hostname" since it was expected that addresses would change much faster than PTR RRs could be maintained. IPv6 could have been a dramatic unequivocal improvement over IPv4. instead it's just bigger addresses, and makes all non-address-size-related problems worse. thanks for asking. From bicknell at ufp.org Wed May 30 17:53:13 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 30 May 2007 17:53:13 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465DD6DF.10701@bogomips.com> References: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> Message-ID: <20070530215313.GA53938@ussenterprise.ufp.org> In a message written on Wed, May 30, 2007 at 12:56:15PM -0700, John Paul Morrison wrote: > I'm curious about the opposition to EUI64. The process for numbering It's quite simply the worst of all worlds. Pick your reason: * EUI-48 is here to stay, even if we run out. Or are we going to replace every bit of deployed ethernet, fddi, and token ring silicon? * If EUI-64 eliminated the need for duplicate address detection, it would be a step forward. It doesn't, so we have that code complexity. * We still have to handle collisions. Duplicate addresses are bad. Are you going to let your PBX get taken out for even a few seconds because of a collision with a duplicate address by stateless autoconfig? * It's a permanent cookie that identifies the user. * If we assume randomized addresses to fix the cookie issue, and we simply use DAD to make sure there are no duplicates, than it's AppleTalk like, and it did quite happily in 16 bits rather than 64, even with large subnets. * Subnets are sparse, and I would argue getting sparser. Where I had 4096 host subnets in 1993, I now have 32 host subnets because virtual interfaces and vlans are now free. Why would anyone think of providing more host bits? * It puts a fixed boundary in the system. CIDR taught us fixed boundaries are bad. Fortunately no one has put them in silicon yet, but it will happen, and it will be bad. * Getting just an address is useless. You can't even browse just the web without nameservers as well. * The system is not extensible to other attributes, so it has to be thrown out entirely. (DHCP6) * Users with servers are going to fixed assign them, in order, from the bottom, because they put in static DNS, IP's in load balancers, and so on. The protocol dictates these uses waste on the order of 56+ bits. * Since they are sparse, they make designing robust hardware more difficult. Your router can't have enough ram for 2^64 entries per subnet, but if it doesn't there's a DDOS potential when you get scanned. You will get scanned, even in IPv6. * When you swap out hardware, your interface changes, screwing up DNS, access lists, and other items. Do you want a BGP session that won't come back because you replaced a faulty card? When it comes to "auto configuration", AppleTalk did it easier, DECNet did it better. The market has spoken. > EUI64: I know stateless auto-config isn't for routers, but that > doesn't mean some protocol like it couldn't be used to bring up router > interfaces betwewen the same OSPF/IS-IS area. There's often no point > to having an IP address on an interface, when a link local or > unnumbered address would do. Other protocols don't even use them > explicitly. There's lots of reasons to have IP's unique IP's on a router interface: * So you can set up DNS to make traceroute et all useful. * So you can configure protocols like BGP, MSDP, IPSec and others to it. * So you can explicitly reach the device over various paths. * So you can test the device on specific interfaces. * So you can have physical addresses independent of virtual addresses. I'm sure I forgot a few. > For some (imaginary) router you would simply have: Humm, smells like DecNet to me. > Nowadays, hosts often have multiple, dynamic interfaces, so it would > be nice to have a single host identifier, and let eui64 and icmp > router solicitation or > other dynamic protocols figure out the routing. No they don't. I don't know where people get this crazy idea. Yes, my laptop has wired and wireless ethernet. The times I go between the two are few and far between. When I do, it's because one is broken, and there's no state to move to the other connection. Yes, my server has two ethernet ports, plugged into the same VLAN on two different switches, running NIC Teaming so both are never active at the same time, and sharing a virtual address. I would venture that less than 1/100th of a percent of all machines on the Internet right now have two active interfaces in two different subnets. I'll bet 80% of them are routers of some sort. Think of all the home PC's...the work desktops, the vast numbers do NOT have two connections. Of the legit servers that are on two networks, most are front end / back end splits, and they are not dynamic, and they do not interchange in any way. -- 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 jeroen at unfix.org Wed May 30 18:05:00 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 30 May 2007 23:05:00 +0100 Subject: [ppml] EUI-64 and autoconfig & RA vs DHCPv6 (Was: Those pesky ULAs again) In-Reply-To: <20070530215313.GA53938@ussenterprise.ufp.org> References: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <20070530215313.GA53938@ussenterprise.ufp.org> Message-ID: <465DF50C.90603@spaghetti.zurich.ibm.com> Leo Bicknell wrote: > In a message written on Wed, May 30, 2007 at 12:56:15PM -0700, John Pau= l Morrison wrote: >> I'm curious about the opposition to EUI64. The process for numberin= g >=20 > It's quite simply the worst of all worlds. Pick your reason: [couple of good points snipped above and below ;) ] > * Getting just an address is useless. You can't even browse just the > web without nameservers as well. > * The system is not extensible to other attributes, so it has to be > thrown out entirely. (DHCP6) There is an RA bit which says "look at another managed/stateful protocols" (AdvManagedFlag + AdvOtherConfigFlag in radvd.conf), so you don't throw it out completely, but indeed you do replace it mostly. A lot of people use DHCPv4 + RA for IPv6, which saves on doing extra configuration for DHCPv6, also because not all the client/server tools are there yet I guess. Note that newer versions of radvd include the following config option: 8<-------------------------------------------------------------- RDNSS (Recursive DNS server) definitions are of the form: RDNSS ip [ip] [ip] { list of rdnss specific options }; -------------------------------------------------------------->8 So what you state is not entirely true > * Users with servers are going to fixed assign them, in order, from the= > bottom, because they put in static DNS, IP's in load balancers, and s= o > on. The protocol dictates these uses waste on the order of 56+ bits.= True. BUT it is not the protocol that 'dictates' it. As Paul Vixie mentioned, you can simply use /124's or whatever. That is your pick, it is your network after all and there you are king, queen and ruler. RIR allocation policies currently do think of /64s + /48s respectively for a link link and a site. As such folks will expect those sizes to be allocated. All that said. The EUI-64 autoconfig mode does come in handy in a certain chunk of space: fe80::/64 - Link Locals. But indeed this does not need to be used for the rest of the network. This part does solve the dentist office network, just plug and play, no config required. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jmorrison at bogomips.com Wed May 30 18:19:39 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Wed, 30 May 2007 15:19:39 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <3935.1180556876@sa.vix.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <3935.1180556876@sa.vix.com> Message-ID: <465DF87B.1040203@bogomips.com> Paul_Vixie at isc.org wrote: >> I'm curious about the opposition to EUI64. >> > > i want to know when a host comes onto my network. i want to have a chance > to set a particular address for it. i want to be able to do an RFC2136 DNS > Dynamic Update to set the AAAA and/or PTR RR. i want to be able to tell it > what the local name servers are. and i want to be able to use non-sparse > addressing, such as a /112 (65536 possible hosts) rather than a /64 (which > is 18446744073709551615 possible hosts) per subnet. > But it seems usable or at least could be improved/built on. Is there a reason not to have at least /80 on a 48 bit MAC layer? If you're building a network within an AS, you just need an address/loopback for each node or router, and information about areas - assuming a link state protocol. Information about "subnets" can be built into the area ids (you often see OSPF areas represented as IP addresses), it can be IP unnumbered if the physical layer supports this, and I've recently seen some IP un-numbered for Ethernet. Isn't it sufficient to push down a routing prefix/area id and then use the 48 bit MAC for local connectivity instead of bothering with ARP? If I have a router with 10 ethernets and 10 hosts, do you really need 10 subnets, if they are all in the same IGP area id and share a common routing prefix? Or the same with a single cable-modem interface and 10,000 downstream subscribers - seen lots of IPv4 kludges where you keep adding /24s to an interface, on top of having to update DHCP. Knowing when a host comes on your network doesn't seem any different or more/less secure than with DHCP, and larger networks will rely on layer 2 mechanisms (802.1x, PAP/CHAP etc). On a large network I would probably want EUI-64 or something like it, with DHCPv6 simply to hand out a prefix (area) and DNS, leaving the MAC address as the lower bits. Was there a draft or published RFC on what you mention? For EID/RID, well who knows what form it will eventually take. Maybe true border routers/eBGP will just get bigger and bigger, while (fully meshed) iBGP disappears, freeing core routers to switch labels (wasn't this the early MPLS promise?) or IPv6 flows or extension headers with the destination ASN embedded in the IP address. Seems like there are lots of prefixes, but much fewer AS's and even fewer ways to exit an AS. One hopes a solution will converge :-) Or silicon could outstrip the public Internet's capacity for growth. > >> Maybe everyone was just too excited about plug-n-play hype back in 1995, >> and it seemed like a good idea to make IPv6 more dynamic, or maybe we're >> also so ingrained with IPv4 that we don't think about other approaches. >> > > you're on the right track. people who i trusted to know what the IETF was > and how it worked, told me in 1995 that IPv6 had "rapid renumbering" as one > of its fundamental design requirements. the idea was to be able to add and > delete prefixes from a LAN as an enterprise added and deleted transit > providers. so, lightweight multihoming would be a side effect of rapid > renumbering. subnets and hosts would have more than one prefix, and each > prefix could have its own exit gateway (or share one). > > none of that happened. so the entire dynamic architecture that EUI64 was > supposed to be part of hasn't happened. but unlike 8+8 and A6/DNAME, the > IETF hasn't abolished or deprecated EUI64 (yet?). so we're doing DHCPv6 > and letting the market sort out which approach is better. > > >> You've mentioned the split between EID/RID, and I don't know that that's >> *not* possible with IPv6 - I would think that v6 flow labels, header >> stacking and/or OSPF opaque LSAs and/or MPLS could all work here to keep >> routing scalable. >> > > i hope i didn't say it wasn't possible. i said the lack of an EID/RID split > was IPv4's major problem, and IPv6 either did nothing to solve it, or made it > worse, or made it harder to solve, or perhaps all three. v6 flow labels were > put in to make it possible to renumber a TCP6 endpoint without teardown and > re-setup of sessions. anybody got that working yet? > > header stacking will probably go the way of RH0 if it hasn't already, but > maybe there's hope -- is there an RFC that shows how this would work for > mobile IP without requiring that i tunnel the traffic in still-open TCP > sessions through the gateway i was nearest to when i opened the session? > > i guess i'm insufficiently imaginative since i can't think of how MPLS or > OSPF can be used to scale a global (exterior) internet routing system. > > >> Some consensus I got out of reading the IETF 68 was that there's no need for >> panic about routing in the short term, and on the other hand there's no >> clear solution long term - in other words the technology is still evolving. >> > > :-). In other words, it's like greenhouse gas, let the grandkids work it out, > we'll just continue to grow the current system incrementally so that when the > solution comes it can have a lot more of our processed output to deal with. > > >> Taking a guess here, I'm wondering if what you're thinking of is how to >> work E.164 or variable length NSAP addresses + Bind into IPv6 routing. >> > > i wanted to use domain names as permanent identifiers and have network-wire > addresses be as irrelevant and ephemeral as IEEE 802. i wanted to pay a setup > and in-flight renumberability complexity tax on every flow, in order to avoid > entrenchment and inertia in the topology. there was talk at one time of an > ICMP6 message for "tell me your hostname" since it was expected that addresses > would change much faster than PTR RRs could be maintained. IPv6 could have > been a dramatic unequivocal improvement over IPv4. instead it's just bigger > addresses, and makes all non-address-size-related problems worse. > > thanks for asking. > _______________________________________________ > 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 Wed May 30 18:31:39 2007 From: paul at vix.com (Paul Vixie) Date: Wed, 30 May 2007 22:31:39 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Wed, 30 May 2007 15:19:39 MST." <465DF87B.1040203@bogomips.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <3935.1180556876@sa.vix.com> <465DF87B.1040203@bogomips.com> Message-ID: <12806.1180564299@sa.vix.com> > > ... and i want to be able to use non-sparse addressing, such as a /112 > > (65536 possible hosts) rather than a /64 (which is 18446744073709551615 > > possible hosts) per subnet. > > But it seems usable or at least could be improved/built on. Is there a > reason not to have at least /80 on a 48 bit MAC layer? leo touched on a number of good reasons for not wanting to always base one's network address upon one's transport address. the only reason ietf reached consensus on the EUI strategy was that at the time, these addresses were expected to be short lived, renumberable while in motion, multihomed most of the time, and so on. once they lost their ephemeral nature, we should have done a nancy reagan ("just say no") to the EUI approach. (so, more guilt.) > For EID/RID, well who knows what form it will eventually take. in all likelihood, the network protocol for split EID/RID won't be IP at all, or at least, not IPv4 or IPv6. meanwhile, to urge things back toward the topic at hand, we need policies for effectively and efficiently allocating IP numbers, including IPv6 numbers, and i remain convinced that asking any RIR to measure the "routability" of these numbers is a recipe for disaster to be prepared while running on a slippery slope carrying scissors. From randy at psg.com Wed May 30 19:06:30 2007 From: randy at psg.com (Randy Bush) Date: Wed, 30 May 2007 16:06:30 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465DF87B.1040203@bogomips.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <3935.1180556876@sa.vix.com> <465DF87B.1040203@bogomips.com> Message-ID: <465E0376.9030001@psg.com> > But it seems usable or at least could be improved/built on. this rationale is the path to 10,000,000 features and unreliable code. the questions should be o it is really necessary? o is there already an existing way to do it? o could it be done more simply? randy From jmorrison at bogomips.com Wed May 30 19:24:16 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Wed, 30 May 2007 16:24:16 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070530215313.GA53938@ussenterprise.ufp.org> References: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <20070530215313.GA53938@ussenterprise.ufp.org> Message-ID: <465E07A0.8090105@bogomips.com> There's some good points but: - how do you get collisions? If even if a 48 bit MAC address is duplicated, this only impacts a layer 2 network. If you have a router, you have a FIB that can sort out whether two duplicate MACs are attached to different interfaces - no collisions there. - subnets aren't necessarily small in a service provider network. So Appletalk with 16 bits wouldn't scale onto a cable-modem head end. We live in a 48 bit MAC world - ethernet, bluetooth, fiber channel etc, I suppose 64 bits was just building in some future proofing. - I think it's been pointed out already that other size subnets do work - you can obscure your mac address in software, and a random mac address doesn't give much more information than a random IP address. - your link local IP address does change but this should be meaningless. You never configure BGP or OSPF router-id's based on a physical IP address anyway. It should always be a loopback, virtual interface. With eBGP, current IPv4 practice typically uses the interface address, but people do use loopbacks on occasion even with IPv4 eBGP sessions, and often with multihop. I see any confusion here as a dependency on IPv4 router configuration syntax. It's just link-local, so for a router (not that it's applicable to routers) it would be like an un-numbered interface only for Ethernet. Router-id's and areas would always be administered. For a host I don't think it's any different (or it shouldn't be), but I may be getting out of my v6 depth here. A basic host/user wouldn't care. An important server would configure other virutal addresses which could live on top of multiple link local IP addresses, and connectivity would survive if one interface went down. (whether ICMPv6 properly deals with hosts updating the routers, I'm not sure). And what's so sacred about a static, physical IP address, as opposed to a static (or even DHCP) virtual IP address? My laptop loses it's connections every time I disconnect from my wired network and enable my own wireless. Or I lose connectivity while my wireless is working, and plug in to a live ethernet port and a static IP address but a dead gateway. Some of this stuff needs to get away from physical addressing anyway to make things work. When we start having IPv6 and EUI-64, link local only connectivity down in USB devices, blue-tooth or whatever, it'll be much more appreciated for the fact that you don't have to know or care about addressing, service discovery etc. Plug in your new hard disk, let the IPv6 stacks talk to each other automatically, either OS to device, or more likely embedded Linux SATA controller talking to the embedded Linux SATA target/disk drive. Leo Bicknell wrote: > In a message written on Wed, May 30, 2007 at 12:56:15PM -0700, John Paul Morrison wrote: > >> I'm curious about the opposition to EUI64. The process for numbering >> > > It's quite simply the worst of all worlds. Pick your reason: > > * EUI-48 is here to stay, even if we run out. Or are we going to > replace every bit of deployed ethernet, fddi, and token ring silicon? > * If EUI-64 eliminated the need for duplicate address detection, it > would be a step forward. It doesn't, so we have that code complexity. > * We still have to handle collisions. Duplicate addresses are bad. > Are you going to let your PBX get taken out for even a few seconds > because of a collision with a duplicate address by stateless autoconfig? > * It's a permanent cookie that identifies the user. > * If we assume randomized addresses to fix the cookie issue, > and we simply use DAD to make sure there are no duplicates, than it's > AppleTalk like, and it did quite happily in 16 bits rather than 64, > even with large subnets. > * Subnets are sparse, and I would argue getting sparser. Where I had > 4096 host subnets in 1993, I now have 32 host subnets because virtual > interfaces and vlans are now free. Why would anyone think of > providing more host bits? > * It puts a fixed boundary in the system. CIDR taught us fixed > boundaries are bad. Fortunately no one has put them in silicon > yet, but it will happen, and it will be bad. > * Getting just an address is useless. You can't even browse just the > web without nameservers as well. > * The system is not extensible to other attributes, so it has to be > thrown out entirely. (DHCP6) > * Users with servers are going to fixed assign them, in order, from the > bottom, because they put in static DNS, IP's in load balancers, and so > on. The protocol dictates these uses waste on the order of 56+ bits. > * Since they are sparse, they make designing robust hardware more > difficult. Your router can't have enough ram for 2^64 entries per > subnet, but if it doesn't there's a DDOS potential when you get scanned. > You will get scanned, even in IPv6. > * When you swap out hardware, your interface changes, screwing up DNS, > access lists, and other items. Do you want a BGP session that won't > come back because you replaced a faulty card? > > When it comes to "auto configuration", AppleTalk did it easier, DECNet > did it better. The market has spoken. > > >> EUI64: I know stateless auto-config isn't for routers, but that >> doesn't mean some protocol like it couldn't be used to bring up router >> interfaces betwewen the same OSPF/IS-IS area. There's often no point >> to having an IP address on an interface, when a link local or >> unnumbered address would do. Other protocols don't even use them >> explicitly. >> > > There's lots of reasons to have IP's unique IP's on a router interface: > > * So you can set up DNS to make traceroute et all useful. > * So you can configure protocols like BGP, MSDP, IPSec and others to it. > * So you can explicitly reach the device over various paths. > * So you can test the device on specific interfaces. > * So you can have physical addresses independent of virtual addresses. > > I'm sure I forgot a few. > > >> For some (imaginary) router you would simply have: >> > > Humm, smells like DecNet to me. > > >> Nowadays, hosts often have multiple, dynamic interfaces, so it would >> be nice to have a single host identifier, and let eui64 and icmp >> router solicitation or >> other dynamic protocols figure out the routing. >> > > No they don't. I don't know where people get this crazy idea. > > Yes, my laptop has wired and wireless ethernet. The times I go > between the two are few and far between. When I do, it's because > one is broken, and there's no state to move to the other connection. > > Yes, my server has two ethernet ports, plugged into the same VLAN > on two different switches, running NIC Teaming so both are never > active at the same time, and sharing a virtual address. > > I would venture that less than 1/100th of a percent of all machines > on the Internet right now have two active interfaces in two different > subnets. I'll bet 80% of them are routers of some sort. Think of all > the home PC's...the work desktops, the vast numbers do NOT have two > connections. Of the legit servers that are on two networks, most are > front end / back end splits, and they are not dynamic, and they do not > interchange in any way. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 dean at av8.com Wed May 30 20:09:59 2007 From: dean at av8.com (Dean Anderson) Date: Wed, 30 May 2007 20:09:59 -0400 (EDT) Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: On Wed, 30 May 2007 michael.dillon at bt.com wrote: > > That's broken. As it has been stated in previous messages > > some days ago, RIR communities can do whatever they want, > > especially if IETF fails. > > That may be true but since the IETF is not failing, there is no reason > for the RIRs to take over any IETF functions. I think there is evidence that the IETF is failing. Rather than a complete list of every failure, I'll just point out that the IETF (that is, the IESG and IAB), have a number of now well documented problems with: corruption conflicts of interest bad faith false statements silencing critics various kinds of deception Millions of dollars are involved in these deceptions. A recent egregious example of corruption, that is, officials profiting from deception, is the Housley authz-extns scandal. Russ Housley and Mark Brown submitted a draft to the IETF standardizing a patented TLS authorization protocol in February 2006. The patent was submitted in January 2005. The problem: They didn't tell the IETF about the patent, in violation of the IETF Policy. Their draft (seven revisions), stated that By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. What is even more egregious about this is that Housley was an IESG member during this time, and knew the policy of the IETF on patent disclosure. The draft was approved by the IESG as a standard in June 2006. Housley still kept mum on the patent. Brown (the other author) finally made a disclosure on November 26, 2006 (right over Thanksgiving). A good eye by Sam Hartman caught the emailed disclosure notice, and thereby discovered the deception. It was discussed by the IESG on the next telechat on 11/30/2006. The IESG announced withdrawal of the approval in February, 2007. It turns out the Housley was paid to write and promote the draft. Housley knew the IETF policy, and didn't disclose the patent, and repeatedly made material false statements. The IETF/ISOC membership and the public lost a legal right by unknowingly using the patented standards. Software patents are usually worth millions of dollars, and patented standards are many time more valuable. I refer one to the definition of "Actionable Fraud". [I used Black's Law Dictionary.] In spite of this, the IESG still (and subsequently!) made Housley Chairman of the IETF and IESG. It is an understatement to say that this is very bad judgment. And after the full extent of the scandal is known, Housley has not even been made to resign. So, I think it is becoming clear that the IETF is an organization that is failing: There is not a majority of honest people on its managing boards to avoid involving the IETF in serious scandal, nor even enough to object to promoting people known to be involved in serious scandal, nor even enough to force a scandalized Chairman to resign after the seriousness of the scandal is known. I think that's pretty bad, and it will only get worse. [Enron and Worldcom come to mind] --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From mack at exchange.alphared.com Wed May 30 20:11:26 2007 From: mack at exchange.alphared.com (mack) Date: Wed, 30 May 2007 19:11:26 -0500 Subject: [ppml] Those pesky ULAs again Message-ID: <859D2283FD04CA44986CC058E06598F840F8B8EE68@exchange4.exchange.alphared.local> Why is anyone even arguing this? The chances of a collision are smaller than the earth getting destroyed by a meteor next year than a collision occurring in the next ten. How many businesses have that in their emergency plans? Any sufficiently large business undergoing a merger is going to have its own address space. Presumably some of that space will not be publicly routed. Will some business still use private IPs internally? Probably so. Is this any different that current NAT scenarios? Probably not. Is there a benefit to setting aside a single /8 as non-routable and proportioning it out as /48s to people who would not qualify for address space? This is already done but not implemented. Please see RFC4193 for more details. FC00/7 is divided in two halves FC00/8 and FD00/8. Only FD00/8 is local and currently specified. It is assumed from RFC4193 (and preceding drafts) that FC00/8 will be centrally managed in the future. I think IANA is the correct group to distribute these to RIRs and the RIRs should be distributing them. I don't think there needs to be a very high bar for these. Charging $500/year will keep 99% from requesting one. The leakage of these addresses to the rest of the world is an entirely different issue and should be handled the same for FC00/8 as FD00/8. The issue for ARIN should be how they are distributed and who gets them. The RFC suggests that everybody should be able to get one. I would even suggest each site that can demonstrate the capability of routing IPv6 and some arbitrary number of computers should be eligible for a /48 from this space. Most people will opt for FD00/8 space if there is any charge at all. On the EUI64 auto-assigned addresses. It is relatively easy to avoid collisions. All numbers assigned with this scheme of converting a MAC to the EUI64 have the L bit (7th bit from the top) set to 1. If you are assigning globally unique addresses this bit should be cleared. If you have a good business case simply buy an OUI from IEEE and create EUI64 numbers that are guaranteed to be unique. >From an ISP standpoint auto-configuration is useful, but not as useful as if it included DNS setup. Someone can put a box on the network and software techs can log into it remotely and complete the configuration. No more trudging from office to office or computer to computer to configure the IP address and netmask. On routing table explosion. There will be a day when routers will have /48s routed. I hope I am retired by then, but it will happen. -- LR Mack McBride Network Administrator Alpha Red, Inc. From stephen at sprunk.org Wed May 30 18:56:38 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 30 May 2007 17:56:38 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com><000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com><00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com><28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no><007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com><465BA1B9.1060003@psg.com><031b01c7a1ca$64904270$dc128953@kantoor.computel.nl><465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net><20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> Message-ID: <060d01c7a31a$3aa641c0$423816ac@atlanta.polycom.com> Thus spake "Thomas Narten" >> sounds like a great idea for all of ipv6 allocation. what is the >> difference ula or pi/pa? > > Here's my take. > > ULAs are not intended to be publically routed by ISPs. While > some may attempt to get ISPs to route them, ISPs will have > clear documentation saying they are not intended to be used > that way, and they are free to filter them. And in fact they > SHOULD be filtered. (I'd say MUST, but since that is not > enforceable...) ISPs SHOULD filter RFC 1918 space, but many don't. If it weren't for the collision issue, you'd be able to get to a heck of a lot of "private" networks. > We have ULAs already. What is missing is centralized ULAs. > I've had enough conversations with people that want to use ULAs > - but simply aren't satisfied with probalistic uniqueness. They > want something more meaningful, like a signed contract that > that can pay some fee for and get some assurance that no one > else is going to get that address. This sort of thing makes > business people happy. People do worry about collisions and > the impact that would have. The RIRs are happy to sign a contract and take a fee to issue unique address space -- it's called PI. All you're going to do is make the RIRs allocate single-sized blocks out of fc00::/8 instead of 2000::/3, creating a v6 swamp that will inherit all of the problems of the v4 swamp. There is absolutely nothing else different about the addresses you propose handing out, except you _hope_ that ISPs won't route them (much) and you _hole_ that the RIRs will set the requirements and fees lower. The policy process can't guarantee the former and may not deliver the latter; OTOH, it could just as easily deliver the latter for PI if desired. > ULAs are intended to be much more easy to obtain than PI > space, because PI space is intended to be publically routed. If PI is tough to get from your RIR, change the policy. ARIN makes getting PIv6 space trivial for a minimum-sized request (the same size you'd get with ULA) and even has explicit policy stating that requests for private use are valid (though, for v4, RFC1918 is encouraged). We have no shortage of address space in v6; policies that discourage PI are _only_ justified to the extent they are needed to keep routing table growth under control. In the case of private use, that limitation doesn't apply since anyone who _really_ intends their block to be for private use won't consume a global routing slot. > PI space, on the other hand, is not useful if it is not publically > routed (generally speaking). Poeple obtaining PI space are > very much assuming it will be publically routed. PI space is useful for anything that needs a globally-unique address that isn't tied to a provider. Whether you advertize it (or portions of it) publicly is up to you. The same would be true for ULA-C, except there's an upproven theory that many people won't accept the route. > ULA space is useful even if not publically routed (and is > intended for uses that do not require public routability). E.g., it > can be used to number infrastructure devices, with assurance > those addresses will not need to change the way public > addresses might. Ditto for PI. 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 iljitsch at muada.com Thu May 31 02:07:16 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 31 May 2007 08:07:16 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070530215313.GA53938@ussenterprise.ufp.org> References: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <20070530215313.GA53938@ussenterprise.ufp.org> Message-ID: On 30-mei-2007, at 23:53, Leo Bicknell wrote: >> I'm curious about the opposition to EUI64. > It's quite simply the worst of all worlds. Pick your reason: Well, IPv6 address configuration certainly _contains_ all worlds: - IPv4-style manual configuration - IPv4-style DHCP address assignment - IPX-style use of the MAC address in the lower bits of the address - AppleTalk-style use of random numbers in the lower bits of the address Interestingly, the availability of 64 bits that a host can pretty much come up with itself have lead to some innovation in the form of crypto-generated addresses that can be used to prove ownership of an address. If anything, 64 bits is on the low side for these uses. :-) Note that it's not all that useful to complain about IETF work that has been done over a decade ago and has since been widely implemented. We'll have to live with it until someone comes up with something better AND a reasonable upgrade path from the current situation to the new model. That being said, considering that IPv6 addresses are 128 bits so we may as well put some of those bits to good use, stateless autoconfiguration with EUI-64s is a pretty good system. You just have to get rid of some IPv4 thinking to appreciate it. > > * EUI-48 is here to stay, even if we run out. Or are we going to > replace every bit of deployed ethernet, fddi, and token ring > silicon? Two out of three ain't bad... But apparently nobody feels we need something better than ethernet if we can just increase the bitrate once in a while. Note that IEEE 1394 (Firewire) uses EUI-64s. > * If EUI-64 eliminated the need for duplicate address detection, it > would be a step forward. It doesn't, so we have that code > complexity. We all run OSPF or IS-IS. That's complex. Duplicate address detection isn't even a blip on the complexity radar. > * We still have to handle collisions. Duplicate addresses are bad. Sure. If you want to have some fun, configure a host with the MAC address of an IPv6 router, then boot up the router. It will be completely dead in the water (for IPv6 on that interface at least) because it can't complete DAD for its link-local address. For a long time, I distrusted stateless autoconfig and used manual configuration for servers (well, A server) but over the years, it has worked so well that I wouldn't hesitate to use it for servers now. > * It's a permanent cookie that identifies the user. Mostly a problem for systems that move around: you get to track them by their MAC address. RFC 3041 temporary addresses fix this, though. > * If we assume randomized addresses to fix the cookie issue, > and we simply use DAD to make sure there are no duplicates, than > it's > AppleTalk like, and it did quite happily in 16 bits rather than 64, > even with large subnets. True, but then you couldn't have fixed addresses with stateless autoconf, which means back to (some kind of) manual configuration for systems that need fixed addresses. > * Subnets are sparse, and I would argue getting sparser. Where I had > 4096 host subnets in 1993, I now have 32 host subnets because > virtual > interfaces and vlans are now free. Why would anyone think of > providing more host bits? Does it matter whether you have 4096 hosts in a subnet or 16 with a 64-bit subnet size? > * It puts a fixed boundary in the system. CIDR taught us fixed > boundaries are bad. Fortunately no one has put them in silicon > yet, but it will happen, and it will be bad. I don't get why a fixed 64-bit boundary is mandated in RFC 3513 either. > * Getting just an address is useless. You can't even browse just the > web without nameservers as well. > * The system is not extensible to other attributes, so it has to be > thrown out entirely. This is VERY untrue. Router advertisements can have options, and even the prefix options have options of their own. New options can be defined as needed, and this is exaclty what happened for resolving DNS server addresses. > * Since they are sparse, they make designing robust hardware more > difficult. Your router can't have enough ram for 2^64 entries per > subnet, but if it doesn't there's a DDOS potential when you get > scanned. > You will get scanned, even in IPv6. Hm, I should test what happens with a neighbor discovery storm some time. Since ICMP must be rate limited in IPv6, I'd assume it wouldn't be as bad as an ARP storm in IPv4, though. > * When you swap out hardware, your interface changes, screwing up DNS, > access lists, and other items. Do you want a BGP session that won't > come back because you replaced a faulty card? You do need manually configured addresses for BGP sessions for exactly this reason, yes. On the other hand, you _don't_ have to have manually configured addresses for any other protocols. I can simply tell all routers in a VLAN this: ! interface TerabitEthernet 39/14.4095 ipv6 address 2001:db8:31:4095::/64 eui-64 ! This helps with the configuration management. (Well actually you don't need global addresses to get OSPFv3 or any other internal routing protocol working.) > When it comes to "auto configuration", AppleTalk did it easier, DECNet > did it better. The market has spoken. And it's saying that IP is better than AppleTalk, DECnet, IPX or CLNP. And despite its limited deployment, IPv6 does share the big advantage of IPv4 for the most part: it has the applications users need. From stephen at sprunk.org Thu May 31 11:41:27 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 31 May 2007 10:41:27 -0500 Subject: [ppml] Small vs Large ISP Address Usage (was: Re: Policy Proposal 2007-6 - Abandoned) References: <462FB3B4.3030609@arin.net><20070426164927.GN22289@shell01.corp.tellme.com><20070427003212.GC39094@ussenterprise.ufp.org><20070427144427.GD12057@shell01.corp.tellme.com> Message-ID: <020901c7a39b$c28d5890$493816ac@atlanta.polycom.com> Thus spake "william(at)elan.net" > In fact the amount of space used by most isps who have < /19 > (which is 80% of ARIN members) is about < 20% of the space > actually allocated by ARIN overall [I did exact study few years > ago, don't have exact numbers handy though; I plan to redo it > based on current data end of 2007 again]. Current stats per ARIN Member Services: # Members % Members % v4 space % fees Xtra Small 390 14.8 0.29 5.7 Small 1,571 59.8 4.64 42.6 Medium 518 19.9 8.92 28.0 Large 71 2.7 6.87 7.7 Xtra Large 73 2.8 79.28 15.8 (The last column didn't come from ARIN, but I calculated it from the fee schedule.) So, basically, we have a situation where 73 members consume nearly 80% of ARIN's v4 space but pay under 16% of the fees. This is another way of looking at the frequent observation (i.e. complaint) that Xtra Large ISPs pay <3.4c/IP whereas Xtra Small ISPs pay up to $5/IP -- a factor of over 100 price difference. I assert that until ISPs are discouraged from consuming as many addresses as possible, which is definitely the case once one passes /14 and pays _nothing_ for additional addresses, any efforts at conservation are doomed. Additionally, until we can get those 73 ISPs to implement real conservation measures (or convert to v6), it is pointless for the rest of the members to do anything. I encourage members to make their opinions on the above stats known to the Board and during any debates about changes to the fee structure. Also, I've read some comments about imposing fees on legacy space or imposing full renewal fees (as opposed to the flat $100/yr) on non-legacy assignments. Currently 86% of assignments are legacy exempt from fees; if non-legacy assignments were subject to the same annual fees as allocations, ARIN estimates it'd collect another $1.6M/yr. A bit of math tells me that applying to the same to legacy assignments/allocations (ARIN doesn't know which are which, actually) would net another ~$9M/yr, assuming it were possible and people didn't return their space rather than pay the fees. No comment on whether it's morally right to do so or whether the legal fees resulting from such a project would be more or less than that amount :) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ed.Lewis at neustar.biz Thu May 31 12:57:01 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 31 May 2007 12:57:01 -0400 Subject: [ppml] Small vs Large ISP Address Usage (was: Re: Policy Proposal 2007-6 - Abandoned) In-Reply-To: <020901c7a39b$c28d5890$493816ac@atlanta.polycom.com> References: <462FB3B4.3030609@arin.net><20070426164927.GN22289@shell01.corp.tellme.com ><20070427003212.GC39094@ussenterprise.ufp.org><20070427144427.GD12057@she ll01.corp.tellme.com> <020901c7a39b$c28d5890$493816ac@atlanta.polycom.com> Message-ID: At 10:41 -0500 5/31/07, Stephen Sprunk wrote: >So, basically, we have a situation where 73 members consume nearly 80% of >ARIN's v4 space but pay under 16% of the fees. This is another way of looking >at the frequent observation (i.e. complaint) that Xtra Large ISPs pay <3.4c/IP >whereas Xtra Small ISPs pay up to $5/IP -- a factor of over 100 price >difference. The fees are not payment for space. The fees go to operate the registry, one primary value being that it maintains the unique relationships between a number resource and the operator making use of it. The beneficiaries of this are not just the operators, it is whoever relies on know the relationships created. That includes anyone doing a reverse map lookup in DNS, doing a lookup in WhoIs, etc. The situation is not analogous to renting an apartment where the dweller pays and derives the benefit. Another way to slice the statistics is to compare the % of Membership and % of Fees and say that is it large ISPs that (per head) are subsidizing the benefit for the smaller ISPs (per head). >I assert that until ISPs are discouraged from consuming as many addresses >as possible, which is definitely the case once one passes /14 and pays >_nothing_ for additional addresses, any efforts at conservation are doomed. >Additionally, until we can get those 73 ISPs to implement real conservation >measures (or convert to v6), it is pointless for the rest of the members to >do anything. I don't believe conservation is a goal. (The goal is fairness in distribution.) Internet number resources are a fiction, we can make more of them when we need. Perhaps we may want to wring out more from IPv4 to forestall inevitable need to transition to a protocol with an expanded address space - but why conserve? There are already more humans than IPv4 addresses, IPv4 isn't big enough for the globe. While there is no reason to waste the space and we do want to make as good use of it as we can, conservation is not what I would call a goal. >I encourage members to make their opinions on the above stats known to the >Board and during any debates about changes to the fee structure. That's why I bothered to reply to this. I think the stats are immaterial. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From leroy at emailsorting.com Thu May 31 16:12:16 2007 From: leroy at emailsorting.com (Leroy Ladyzhensky) Date: Thu, 31 May 2007 16:12:16 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks Message-ID: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> In this suggestion I am not talking about ISP's but this is directed to policy IPv4 assignment for "end-users". The current policy is as follows... Single connection: minimum assignment = /20 (16 class C's) utilization: 25% immediate / 50% in one year. Multi-homed: minimum assignment = /22 (4 class C's) utilization: 25% immediate / 50% in one year. Here is where this policy is lacking, and in my opinion is a complete oversight in ARIN policy. Requesting IP's from ARIN is not always a request for quantity... but ISP independence. Many internet businesses are not ISP's, but businesses that supply a service or a managed solution for other companies via the internet. In this situation ISP independence is critical for the company's survivability and flexability. Imagine this situation: An internet based company provides a specialized service. In order for the companies clients to utilize this service they need to open ports in their firewall. As we know this option in a firewall is based on the IP's of the internet based company. Let's say they have 2000 clients. so that 2000 firewalls that have entries for their IP's. These IP's are from their ISP since this company cannot fulfill the IP requirement as dictated by ARIN's policy (they may only use 75 IP's, not the 508 required by ARIN). then the inevitable happens: the ISP want the company to change to a new block of IP's, they increase their rates, are no longer providing acceptable service, got purchased/went bankrupt or other reasons... needless to say this company is forced to change IP's and 2000 customers now have to make firewall changes or face service disruptions. Depending on the reason this could impact the company's business and possibly loose clients in the process and cost money. This situation is not far fetched and maybe some of us reading this have experienced this ourselves. A company that provides internet based services needs to own its IP's .. that's just good business strategy. But, what happens when a company cannot reach the "quantity commitment"? I guess there is only 2 choices: Stay at risk / or take more than you need. Undoubtedly company's will choose to not be at risk.. so that will just take more then they need. And I guess deep down that just really goes against the very essence of ARIN. Implementing a policy/policy change for end users (internet based businesses, MSP's) to obtain a smaller block of IP's (/24 or /23) would allow companies like this to qualify for a block of IP's and prevent unneeded waste. I would like your comments / experiences on this issue. Thank You, Leroy Ladyzhensky - CCNA, CCDA, CSE -------------- next part -------------- An HTML attachment was scrubbed... URL: From heather.schiller at verizonbusiness.com Thu May 31 16:27:52 2007 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Thu, 31 May 2007 20:27:52 +0000 (GMT) Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> Message-ID: Policies to reduce the minimum assignment from ARIN down to a /24 have been proposed in the past, including the last policy development cycle. You can read archived ppml comments on the subject and meeting transcripts to get a feel for and against the idea. Most recently: http://www.arin.net/policy/proposals/2007_6.html However your example of 75 IP's is significantly smaller than a /24 - which is the generally accepted minimum prefix size passed between providers. If you would also like providers to consider lowering the prefix size they will accept, Nanog might be a better forum, as that is more operational than IP addressing policy. (However don't expect it to be a popular idea, as it would add to routing table growth) ARIN doesn't guarantee the routability of address space, so even if the policy were changed to make the minimum assignment a /25, you'd have to find a provider willing to leak it, and others willing to listen. --Heather ############################################### # Heather Schiller # # Customer Security & IP Address Management # # 800.900.0241 # # security at mci.com # ############################################### On Thu, 31 May 2007, Leroy Ladyzhensky wrote: > In this suggestion I am not talking about ISP's but this is directed to policy IPv4 assignment for "end-users". > > > > The current policy is as follows... > > > > Single connection: minimum assignment = /20 (16 class C's) utilization: 25% immediate / 50% in one year. > > Multi-homed: minimum assignment = /22 (4 class C's) utilization: 25% immediate / 50% in one year. > > > > Here is where this policy is lacking, and in my opinion is a complete oversight in ARIN policy. > > > > Requesting IP's from ARIN is not always a request for quantity... but ISP independence. Many internet businesses are not ISP's, but businesses that supply a service or a managed solution for other companies via the internet. In this situation ISP independence is critical for the company's survivability and flexability. > > > > Imagine this situation: > > > > An internet based company provides a specialized service. In order for the companies clients to utilize this service they need to open ports in their firewall. As we know this option in a firewall is based on the IP's of the internet based company. Let's say they have 2000 clients. so that 2000 firewalls that have entries for their IP's. These IP's are from their ISP since this company cannot fulfill the IP requirement as dictated by ARIN's policy (they may only use 75 IP's, not the 508 required by ARIN). then the inevitable happens: the ISP want the company to change to a new block of IP's, they increase their rates, are no longer providing acceptable service, got purchased/went bankrupt or other reasons... needless to say this company is forced to change IP's and 2000 customers now have to make firewall changes or face service disruptions. Depending on the reason this could impact the company's business and possibly loose clients in the process and cost money. > > > > This situation is not far fetched and maybe some of us reading this have experienced this ourselves. > > > > A company that provides internet based services needs to own its IP's .. that's just good business strategy. > > > > But, what happens when a company cannot reach the "quantity commitment"? I guess there is only 2 choices: Stay at risk / or take more than you need. > > > > Undoubtedly company's will choose to not be at risk.. so that will just take more then they need. And I guess deep down that just really goes against the very essence of ARIN. > > > > Implementing a policy/policy change for end users (internet based businesses, MSP's) to obtain a smaller block of IP's (/24 or /23) would allow companies like this to qualify for a block of IP's and prevent unneeded waste. > > > > I would like your comments / experiences on this issue. > > > > Thank You, > > Leroy Ladyzhensky - CCNA, CCDA, CSE > From alh-ietf at tndh.net Thu May 31 17:06:50 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 31 May 2007 14:06:50 -0700 Subject: [ppml] Keeping the story straight In-Reply-To: References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> Message-ID: <1f8101c7a3c7$9c246a00$d46d3e00$@net> This note from Heather is indirectly contradictory to Paul's complaint about ULA-C. Official or not, policy is already tied to 'routability'. The fundamental question that has to be kept straight is; are the RIRs 'stewards of the address space', or 'stewards of the -publicly routed- address space'. If I listen to Randy's frequent points about 'used in the public Internet', then the core of RIR policy is all about routability. If I listen to the points about 'stewards of the space', then the discussion about length longer than /24 makes absolutely no sense, along with the objections to managing ULA-C. Why shouldn't ARIN allocate/assign an IPv4 block longer than /24 if that is what the customer is asking for? Oh wait, it is because some vocal members only want to have space go the club that actually intends to -route it- in the public Internet. That sounds exactly like a blanket statement about routability to me; where the routing cabal wants to use the allocation policy system to prevent organizations from getting a routing slot. If the systems really are independent, there is no justification for an RIR to reject any request, just provide the appropriate length for the customer need and let them worry about getting it routed. If the systems really are tied, then the bs about 'not guaranteeing routability' needs to go away. Somebody needs to figure out the real story, then try to keep it straight. Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Heather Schiller > Sent: Thursday, May 31, 2007 1:28 PM > To: Leroy Ladyzhensky > Cc: ppml at arin.net > Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks > > > Policies to reduce the minimum assignment from ARIN down to a /24 have > been proposed in the past, including the last policy development cycle. > > You can read archived ppml comments on the subject and meeting > transcripts > to get a feel for and against the idea. > > Most recently: > http://www.arin.net/policy/proposals/2007_6.html > > However your example of 75 IP's is significantly smaller than a /24 - > which is the generally accepted minimum prefix size passed between > providers. If you would also like providers to consider lowering the > prefix size they will accept, Nanog might be a better forum, as that is > more operational than IP addressing policy. (However don't expect it to > be a popular idea, as it would add to routing table growth) ARIN > doesn't > guarantee the routability of address space, so even if the policy were > changed to make the minimum assignment a /25, you'd have to find a > provider willing to leak it, and others willing to listen. > > --Heather > > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Paul_Vixie at isc.org > Sent: Wednesday, May 30, 2007 9:22 AM > To: ARIN PPML > Cc: address-policy-wg at ripe.net > Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > aside from the difficulties pointed out during this thread regarding > enforcement of ULA terms vs. PI terms, there are two other things that > prevent me from thinking well of ULA. > > first, ARIN does not currently consider routability when allocating > address space. non-routable space comes from ietf/iana, not the RIRs. > so, for ARIN to start allocating nonroutable space is a big change. we > would have to define "routable", we could face implied liability for > routability on "normal address space" (even if we continue to disclaim > it in the NRPM as we do now), and we would then walk the slippery slope > of the changing definition "largest" with respect to breidbart's maxim: From bicknell at ufp.org Thu May 31 17:52:45 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 31 May 2007 17:52:45 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <20070530215313.GA53938@ussenterprise.ufp.org> Message-ID: <20070531215244.GA43143@ussenterprise.ufp.org> In a message written on Thu, May 31, 2007 at 08:07:16AM +0200, Iljitsch van Beijnum wrote: > Note that it's not all that useful to complain about IETF work that > has been done over a decade ago and has since been widely > implemented. We'll have to live with it until someone comes up with > something better AND a reasonable upgrade path from the current > situation to the new model. That's where I disagree. The IETF did half the work, then bailed on the other half of the work. All the good stuff about TCP that would survive address changes, A6/DNAME, etc, etc etc has been dropped. Now they want the operational world to clean up the mess. I think it's absolutely the right thing to complain to the IETF. I want to know why the IETF isn't still working on these problems. Have you seen any progress in the last 5 years? I think the ARIN board needs to issue a second statement aimed at the IETF: "The IETF has left IPv6 half finished, which makes it impossible to deploy under the original vision. Given that the IETF has not offered any additional guidance, the RIR community will be left to create the operational parameters on the fly. We believe the industry would be better served if the IETF could complete the work and develop useful deployment standards prior to widespread deployment. The clock is ticking." -- 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 tedm at ipinc.net Thu May 31 17:53:56 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 31 May 2007 14:53:56 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> Message-ID: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Leroy Ladyzhensky > Sent: Thursday, May 31, 2007 1:12 PM > To: ppml at arin.net > Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks > In this suggestion I am not talking about ISP's but this is directed to policy IPv4 assignment for "end-users". > The current policy is as follows... [deleted] > Imagine this situation: >An internet based company provides a specialized service. In order for the companies clients >to utilize this service they need to open ports in their firewall. As we know this option in >a firewall is based on the IP's of the internet based company. Leroy, I'm very sorry but this is based on flawed reasoning. Let me demonstrate: ip-port-rtr0# sh ver | include IOS IOS (tm) 7200 Software (C7200-IK8S-M), Version 12.2(46), RELEASE SOFTWARE (fc1) ip-port-rtr0#config t Enter configuration commands, one per line. End with CNTL/Z. ip-port-rtr0(config)#access-list 100 permit ip host mail.ipinc.net any ip-port-rtr0(config)#exit ip-port-rtr0#sh access-list 100 Extended IP access list 100 permit ip host 65.75.192.11 any Now I'm not going to belabor the point with a long drawn out example of how to setup remote management of access lists on routers - just be aware that with Cisco IOS when it boots it will interpret an access list that uses DNS names - the stored config may contain a DNS name not an IP address. Obviously you have to put the config into the router's nvram through other means than "write mem" but that is trivial. Other enterprise level firewalls have the same capability. And Cisco has tools that allow a single console to manage 2000 routers if need be - assuming the admin isn't educated enough to do it with free open source scripting tools that have been around for the last 20 years. (I assume you know that Cisco routers can be made into firewalls with IOS Firewall Feature set) > Let?s say they have 2000 clients. so that 2000 firewalls that have entries for their IP's. Then you see, they have a choice. They can specify El-Cheapo dlink or otherwise crummy "firewalls" (which will not be IPv6 compliant and thus have to be switched out in a few years anyway) that have ZERO capability for remote management, and cannot use DNS in access list configurations, or they can specify REAL enterprise-level firewalls that they can remotely manage on their customers' behalf with configurations that are not full of static IP addresses. The rest of your reasoning was all stacked on the idea you have to use static IPs at the customer site, so in disproving that, it makes the rest of the argument moot. I am sure your capabable of contriving more un-real world examples to argue the point, the fact is, anyone with 2000 clients better have given this matter serious thought and had a much longer and more through ISP selection process than just calling the Yellow Pages and getting the cheapest hosting in town. Before getting yourself into this kind of corner you had better have allocated sufficient IP addresses in advance for future growth and be pretty sure your provider isn't some fly-by-night operator who is going to take away your IP numbers for no good reason. Fundamentally this is an arguement that boils down to "my lack of planning is the rest of the world's problem" or more accurately, "I figured out a way to make a buck that involves causing the rest of the world to spend more money" As was said, allowing smaller advertisements causes everyone else on the Internet to spend more money. It helps a few companies and individuals so that they can get away with half-assed El Cheapo deployments with Dlink routers, at the cost of the rest of the individuals and companies on the Internet paying for it. It is better for everyone to not provide an environment that would encourage a company to contemplate having 2000 Dlink routers out there with statically assigned IP addresses, but instead force them to contemplate 2000 IOS firewalls with a much more expensive, yet remotely manageable, setup. Ted From jeroen at unfix.org Thu May 31 18:04:24 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 31 May 2007 23:04:24 +0100 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070531215244.GA43143@ussenterprise.ufp.org> References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <20070530215313.GA53938@ussenterprise.ufp.org> <20070531215244.GA43143@ussenterprise.ufp.org> Message-ID: <465F4668.9030302@spaghetti.zurich.ibm.com> Leo Bicknell wrote: [..] > I think the ARIN board needs to issue a second statement aimed at the > IETF: I think that instead of complaining, you should try to participate in the IETF process, which, like the RIR processes, are completely open. Several people from the IETF have extended their arms already several times in the direction of the RIR's and NANOG, there have even been debates about this. That you did not participate in any of these things in the last 10 years, tsja... Don't complain when you didn't try to do anything about it yourself. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Thu May 31 18:20:11 2007 From: randy at psg.com (Randy Bush) Date: Thu, 31 May 2007 15:20:11 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465F4668.9030302@spaghetti.zurich.ibm.com> References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <20070530215313.GA53938@ussenterprise.ufp.org> <20070531215244.GA43143@ussenterprise.ufp.org> <465F4668.9030302@spaghetti.zurich.ibm.com> Message-ID: <465F4A1B.9090509@psg.com> > I think that instead of complaining, you should try to participate in > the IETF process, which, like the RIR processes, are completely open. been there. have the bloody tee shirt. the meetings are open. the minds far less so. randy From randy at psg.com Thu May 31 18:23:20 2007 From: randy at psg.com (Randy Bush) Date: Thu, 31 May 2007 15:23:20 -0700 Subject: [ppml] rubber/road Message-ID: <465F4AD8.6070104@psg.com> so, i have two multi-homed racks, one beast coast (equiburn), one left coast (westin). let's be polite and not discuss if and how they handle v6 today. let's say i wanted to do it in whatever is the current fashion for correctly. do i get two /32s from arin? two /48s? how much will that cost today? how much will it cost me in two years? randy From dlw+arin at tellme.com Thu May 31 18:41:46 2007 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 31 May 2007 15:41:46 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> Message-ID: <20070531224146.GH4316@shell01.corp.tellme.com> On Thu, May 31, 2007 at 04:12:16PM -0400, Leroy Ladyzhensky wrote: > Implementing a policy/policy change for end users (internet based businesses, MSP's) to obtain a smaller block of IP's (/24 or /23) would allow companies like this to qualify for a block of IP's and prevent unneeded waste. > > I would like your comments / experiences on this issue. As the author of 2007-6, I think you are on the right track, although your reasoning needs to be tightened up a bit. I enitrely agree that there's good reasons for decreasing the minimum PI size to /24, but the community seems to presently believe otherwise. Specifically, there is concern about such a policy creating a further strain on the remaning space, leading to faster IPv4 exhaustion and further increases in routing table size. There's also some fraud concerns. You should really read the ppml archives with an eye to 2007-6. You may want to read the meeting transcripts from the last public meeting in San Juan. Good luck. -David From jeroen at unfix.org Thu May 31 18:47:49 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 31 May 2007 23:47:49 +0100 Subject: [ppml] rubber/road In-Reply-To: <465F4AD8.6070104@psg.com> References: <465F4AD8.6070104@psg.com> Message-ID: <465F5095.40209@spaghetti.zurich.ibm.com> Randy Bush wrote: > so, i have two multi-homed racks, one beast coast (equiburn), one left > coast (westin). let's be polite and not discuss if and how they handle > v6 today. > > let's say i wanted to do it in whatever is the current fashion for > correctly. do i get two /32s from arin? Can you justify for the need of a /32 at each site, if so, then why not. If you can't justify a /32 each, you might want to try justifying a single /32. The side effect, if you split that up into chunks of /48's or /40's you might run into filters, and that is not so weird as (afaik) the policy explicitly states you have to announce the aggregate. Of course nobody can stop you from trying (to bribe people with good whisky to accept your prefix anyway :) > two /48s? If you can justify that, why not. They definitely are 2 sites, so a /48 each sounds logical. It is the minimum allocation size. Routingwise these /48's should get through. > how much will that cost today? As you already have IPv4 space (afaik, though maybe for you that is legacy stuff you don't pay for?) nothing, as the fees are waved. > how much will it cost me in two years? The amount that is the most of either your IPv4 or the IPv6 one. See a couple of days back where somebody disclosed that. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From tedm at ipinc.net Thu May 31 18:56:34 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 31 May 2007 15:56:34 -0700 Subject: [ppml] rubber/road In-Reply-To: <465F5095.40209@spaghetti.zurich.ibm.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Jeroen Massar >Sent: Thursday, May 31, 2007 3:48 PM >To: Randy Bush >Cc: Public Policy Mailing List >Subject: Re: [ppml] rubber/road > >> how much will it cost me in two years? > >The amount that is the most of either your IPv4 or the IPv6 one. >See a couple of days back where somebody disclosed that. > In 2 years a policy could be submitted and approved that would radically raise prices on the IPv6 block and require you to pay for both blocks. As long as both allocations (IPv4 and IPv6) are separate, the fear of getting jacked over in the future is a real possibility. this is why I suggested a while ago that IPv6 automatically be allocated to all paying IPv4 holders. If the IP registration fee was a lump sum that covered both IPv6 and IPv4 allocations, it would be more difficult down the road for a price raise on IPv6 to get through. (Since that would not exist as a separate 'product' of a RIR) Ted From jeroen at unfix.org Thu May 31 19:04:47 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 01 Jun 2007 00:04:47 +0100 Subject: [ppml] rubber/road In-Reply-To: References: Message-ID: <465F548F.8080005@spaghetti.zurich.ibm.com> Ted Mittelstaedt wrote: [..] > In 2 years a policy could be submitted and > approved that would radically raise prices on the IPv6 block and > require you to pay for both blocks. As long as both allocations > (IPv4 and IPv6) are separate, the fear of getting jacked over in > the future is a real possibility. My magic crystal ball tells me that IPv4 address space will become pricey, as that is the resource running out, not IPv6 space. You can make all kinds of weird assumptions about the future, one thing is sure: IPv4 address space won't be available anymore from the RIRs in a couple of years. The blackmarket will have it for you though. > this is why I suggested a while ago that IPv6 automatically be > allocated to all paying IPv4 holders. If the IP registration fee > was a lump sum that covered both IPv6 and IPv4 allocations, it would > be more difficult down the road for a price raise on IPv6 to get > through. > (Since that would not exist as a separate 'product' of a RIR) As stated before, by others also, giving "free address space" to folks who clearly are not requesting it is not a solution. The IPv6 fee waiver is already in place for the last 2+ years. If you didn't use that upto now, then there is not much you can complain about. Do also remember that the membership of the RIR set the 'prices on address space' if you could call it that. As such, you and everybody else would be part of that decision process. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jmorrison at bogomips.com Thu May 31 19:06:29 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Thu, 31 May 2007 16:06:29 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <20070531224146.GH4316@shell01.corp.tellme.com> References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> <20070531224146.GH4316@shell01.corp.tellme.com> Message-ID: <465F54F5.2000605@bogomips.com> What about splitting the difference and resubmitting with /23? Or demonstrate existsing multi-homing with a non-PI /24? I thought 2007-6 was very pragmatic. I've seen plenty of customers move to getting their own ASNs and being multi homed in every sense except being forcibly tied to one of their upstreams by not having PI address space. I probably shouldn't be surprised at the knee-jerk response against 2007-6, but I was surprised to see it go down in flames after so little apparent discussion and opposition. David Williamson wrote: > On Thu, May 31, 2007 at 04:12:16PM -0400, Leroy Ladyzhensky wrote: > >> Implementing a policy/policy change for end users (internet based businesses, MSP's) to obtain a smaller block of IP's (/24 or /23) would allow companies like this to qualify for a block of IP's and prevent unneeded waste. >> >> I would like your comments / experiences on this issue. >> > > As the author of 2007-6, I think you are on the right track, although > your reasoning needs to be tightened up a bit. I enitrely agree that > there's good reasons for decreasing the minimum PI size to /24, but > the community seems to presently believe otherwise. > > Specifically, there is concern about such a policy creating a further > strain on the remaning space, leading to faster IPv4 exhaustion and > further increases in routing table size. There's also some fraud > concerns. > > You should really read the ppml archives with an eye to 2007-6. You > may want to read the meeting transcripts from the last public meeting > in San Juan. > > Good luck. > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heather.schiller at verizonbusiness.com Thu May 31 19:20:18 2007 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Thu, 31 May 2007 23:20:18 +0000 (GMT) Subject: [ppml] Keeping the story straight In-Reply-To: <1f8101c7a3c7$9c246a00$d46d3e00$@net> References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> <1f8101c7a3c7$9c246a00$d46d3e00$@net> Message-ID: On Thu, 31 May 2007, Tony Hain wrote: > This note from Heather is indirectly contradictory to Paul's complaint about > ULA-C. Official or not, policy is already tied to 'routability'. > Policy may be indirectly tied to routability - but the official policy statement in the NRPM is that routability is not guaranteed. http://www.arin.net/policy/nrpm.html#six42 You are welcome to propose a policy to alter or remove the statement and let the community hash it out. Here's the form: http://www.arin.net/policy/irpep.html > > The fundamental question that has to be kept straight is; are the RIRs > 'stewards of the address space', or 'stewards of the -publicly routed- > address space'. If I listen to Randy's frequent points about 'used in the > public Internet', then the core of RIR policy is all about routability. If I > listen to the points about 'stewards of the space', then the discussion > about length longer than /24 makes absolutely no sense, along with the > objections to managing ULA-C. > > Why shouldn't ARIN allocate/assign an IPv4 block longer than /24 if that is > what the customer is asking for? Oh wait, it is because some vocal members > only want to have space go the club that actually intends to -route it- in > the public Internet. That sounds exactly like a blanket statement about > routability to me; where the routing cabal wants to use the allocation > policy system to prevent organizations from getting a routing slot. If the > systems really are independent, there is no justification for an RIR to > reject any request, just provide the appropriate length for the customer > need and let them worry about getting it routed. If the systems really are > tied, then the bs about 'not guaranteeing routability' needs to go away. > > > Somebody needs to figure out the real story, then try to keep it straight. > Tony > I can't tell from your email if you want: - ARIN to guarantee routability - not make a formal statement on routability (thus implying anything or nothing) - You want ARIN/RIR's to declare/refine their function/mission statement - or you just want to ask a bunch of rhetorical questions to get people thinking and you may or may not have your own opinion? (..and I'm not intending to be snide.. it's just that sometimes email is a lousy method of communication and I really can't tell) > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> Heather Schiller >> Sent: Thursday, May 31, 2007 1:28 PM >> To: Leroy Ladyzhensky >> Cc: ppml at arin.net >> Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks >> >> >> Policies to reduce the minimum assignment from ARIN down to a /24 have >> been proposed in the past, including the last policy development cycle. >> >> You can read archived ppml comments on the subject and meeting >> transcripts >> to get a feel for and against the idea. >> >> Most recently: >> http://www.arin.net/policy/proposals/2007_6.html >> >> However your example of 75 IP's is significantly smaller than a /24 - >> which is the generally accepted minimum prefix size passed between >> providers. If you would also like providers to consider lowering the >> prefix size they will accept, Nanog might be a better forum, as that is >> more operational than IP addressing policy. (However don't expect it to >> be a popular idea, as it would add to routing table growth) ARIN >> doesn't >> guarantee the routability of address space, so even if the policy were >> changed to make the minimum assignment a /25, you'd have to find a >> provider willing to leak it, and others willing to listen. >> >> --Heather >> > > >> -----Original Message----- >> From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- >> admin at ripe.net] On Behalf Of Paul_Vixie at isc.org >> Sent: Wednesday, May 30, 2007 9:22 AM >> To: ARIN PPML >> Cc: address-policy-wg at ripe.net >> Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again >> >> aside from the difficulties pointed out during this thread regarding >> enforcement of ULA terms vs. PI terms, there are two other things that >> prevent me from thinking well of ULA. >> >> first, ARIN does not currently consider routability when allocating >> address space. non-routable space comes from ietf/iana, not the RIRs. >> so, for ARIN to start allocating nonroutable space is a big change. we >> would have to define "routable", we could face implied liability for >> routability on "normal address space" (even if we continue to disclaim >> it in the NRPM as we do now), and we would then walk the slippery slope >> of the changing definition "largest" with respect to breidbart's maxim: > > _______________________________________________ > 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 31 19:24:30 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 31 May 2007 19:24:30 -0400 Subject: [ppml] rubber/road In-Reply-To: <465F4AD8.6070104@psg.com> References: <465F4AD8.6070104@psg.com> Message-ID: <20070531232430.GB48716@ussenterprise.ufp.org> In a message written on Thu, May 31, 2007 at 03:23:20PM -0700, Randy Bush wrote: > so, i have two multi-homed racks, one beast coast (equiburn), one left > coast (westin). let's be polite and not discuss if and how they handle > v6 today. > > let's say i wanted to do it in whatever is the current fashion for > correctly. do i get two /32s from arin? two /48s? how much will that > cost today? how much will it cost me in two years? For this exercise, I'm going to assume you have no ARIN space today (v4 or v6). If you do, there may be other ways to get space, and at the very least there may be the question why you're not using your current space. I'm also going to assume you want IPv6 space only, and have no interest in IPv4 space. We could explore what both of those do to change things, if you're interested. This is also my own interpretation of the policy, ARIN staff would of course be authoritative. http://www.arin.net/policy/nrpm.html#six58 The policy states you must qualify under the IPv4 policy. Note, you do not need to have IPv4 resources, you just have to qualify under that policy, so we look at: http://www.arin.net/policy/nrpm.html#four3 You state that you are multi-homed, so 4.3.2.2 applies, a /22 minimum. 4.3.3 also applies, you need 25% immediate need, and 50% in one year. Basically you have to demonstrate you will use 256 addresses day 1, and 512 within a year. That qualifies you for IPv4, which qualifies you for IPv6. I don't see anything to prevent you from combining this across sites, so you need 128 addresses in use at each site day 1, and 256 at each site in one year. You now qualify, so back to the IPv6 section (http://www.arin.net/policy/nrpm.html#six58), you should get a /48 for qualifying under the IPv4 plan. ARIN should reserve a /44 for you. Up to this point the policy is relatively clear to me, and you now have a single /48, and should be able to assign /56's to both your sites (or /49's, or whatever you want). Can you multi-home that way? Well, if you have one provider in common and announce the /48 out of both locations to be safe, probably just fine. Here's the unclear part to me: http://www.arin.net/policy/nrpm.html#six583 In many parts of the polocy we allow a /48 to be allocated to a "site". You have two sites in this example, and I think you could argue 6.5.8.3 could allow you to request a second /48 (which should come out of your /44 reserve) for the second site. Now, with regard to fees. You have either a /47 or a /48, depending on that last part. Per http://www.arin.net/billing/fee_schedule.html, the initial fee should be $1,250, but since you're signing up before Dec 1 2007 you get the waver which makes that $500. You will then pay $100 per year in annual maintenance as an end user. See, isn't it simple. :) I will note, you could get your /22 of IPv4 at the same time. The justification above gets you there. The initial fee is $1,250. The yearly maintenance is per org-id, so for both it's the same $100. So, $1,750 + $100 a year gets you both IPv4 and IPv6 resources. Now that I've broken it down I fully suspect someone will pick my analysis apart, I'm sure I got something wrong, just hopefully it's not too major of a detail. -- 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 JOHN at egh.com Thu May 31 19:39:15 2007 From: JOHN at egh.com (John Santos) Date: Thu, 31 May 2007 19:39:15 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: Message-ID: <1070531191229.386B-100000@Ives.egh.com> This is completely wrong. In Leroy's scenario, his company does not own and does not manage the 2000 firewalls. Those belong to his customers. He is not providing a soup-to-nuts internet service to those customers. He is providing one specific service on one (or a small) number of specific ports, from one (or a small number of specific) servers. The *CUSTOMER* has to open the *CUSTOMER'S* firewall to those specific ports and services in order to utilize Leroy's service. It is the 2000 customers who would have to pay the cost. It may be small for each, but its cumulative, and will certainly generating lots of support calls back to Leroy's company. My company is in a similar situation to Leroy's customers. We have an external mail filtering service. Our published MX records point to the service, and they then forward the (filtered for spam, viruses, RBL, etc.) mail to us, so we have had to open up our firewall to SMTP from their specific IP addresses. We are certainly *not* going to let them manage our firewalls for us, nor are we going to willy-nilly change our firewall rules on their request without minimally verifying the origin of the request (a support call to them.) Multiply by several thousand customers. If they were to start changing IP addresses frequently, we would start looking for a new service provider. This is an *extremely* unlevel playing field, since ACME GIANT ASP, INC. (which is many times the size of Leroy's company), could easily justify an allocation, and thus could promise their customers that their IP addresses and firewall rule would never change. Of course, Leroy could game the system and provide each of his customers with a single, unique IP address (thus requiring 8 class C's) and then forward them all to the same handfull of servers at his firewalls. So is it better for the overburdened routers to route to one Class C (what Leroy actually requires), or to 8 of them? (Especially given there is no guarantee the 8 would be contiguous and thus could be treated as a single /21 for routing purposes.) On Thu, 31 May 2007, Ted Mittelstaedt wrote: > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Leroy Ladyzhensky > > Sent: Thursday, May 31, 2007 1:12 PM > > To: ppml at arin.net > > Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks > > > In this suggestion I am not talking about ISP's but this is directed to > policy IPv4 assignment for "end-users". > > > The current policy is as follows... > > [deleted] > > > Imagine this situation: > > >An internet based company provides a specialized service. In order for the > companies clients > >to utilize this service they need to open ports in their firewall. As we > know this option in > >a firewall is based on the IP's of the internet based company. > > Leroy, > > I'm very sorry but this is based on flawed reasoning. Let me demonstrate: > > ip-port-rtr0# sh ver | include IOS > IOS (tm) 7200 Software (C7200-IK8S-M), Version 12.2(46), RELEASE SOFTWARE > (fc1) > ip-port-rtr0#config t > Enter configuration commands, one per line. End with CNTL/Z. > ip-port-rtr0(config)#access-list 100 permit ip host mail.ipinc.net any > ip-port-rtr0(config)#exit > ip-port-rtr0#sh access-list 100 > Extended IP access list 100 > permit ip host 65.75.192.11 any > > Now I'm not going to belabor the point with a long drawn out example of how > to setup > remote management of access lists on routers - just be aware that with Cisco > IOS when it > boots it will interpret an access list that uses DNS names - the stored > config may contain > a DNS name not an IP address. Obviously you have to put the config into the > router's > nvram through other means than "write mem" but that is trivial. > > Other enterprise level firewalls have the same capability. And > Cisco has tools that allow a single console to manage 2000 routers if need > be - assuming > the admin isn't educated enough to do it with free open source scripting > tools > that have been around for the last 20 years. (I assume you know that Cisco > routers can > be made into firewalls with IOS Firewall Feature set) > > > Let?s say they have 2000 clients. so that 2000 firewalls that have entries > for their IP's. > > Then you see, they have a choice. They can specify El-Cheapo dlink or > otherwise crummy > "firewalls" (which will not be IPv6 compliant and thus have to be switched > out in a few > years anyway) that have ZERO capability for remote management, and cannot > use DNS in > access list configurations, or they can specify REAL > enterprise-level firewalls that they can remotely manage on their customers' > behalf > with configurations that are not full of static IP addresses. > What makes you think Leroy is specifying anything at the customer's premises? The customer is choosing (one hopes!) their own firewall, router, ISP, etc. > The rest of your reasoning was all stacked on the idea you have to use > static IPs > at the customer site, so in disproving that, it makes the rest of the > argument moot. > The customers don't (necessarily) have static IPs. Leroy's company is the one that needs the static IPs. > I am sure your capabable of contriving more un-real world examples to argue > the point, > the fact is, anyone with 2000 clients better have given this matter serious > thought and > had a much longer and more through ISP selection process than just calling > the Yellow > Pages and getting the cheapest hosting in town. Before getting yourself > into this kind > of corner you had better have allocated sufficient IP addresses in advance > for future > growth and be pretty sure your provider isn't some fly-by-night operator who > is going > to take away your IP numbers for no good reason. > Or never quadruple their rates or go into direct competition with him or otherwise make their ongoing business relationship untenable? > Fundamentally this is an arguement that boils down to "my lack of planning > is the > rest of the world's problem" or more accurately, "I figured out a way to > make a buck that > involves causing the rest of the world to spend more money" > > As was said, allowing smaller advertisements causes everyone else on the > Internet to > spend more money. It helps a few companies and individuals so that they can > get away > with half-assed El Cheapo deployments with Dlink routers, at the cost of the > rest of the > individuals and companies on the Internet paying for it. It is better for > everyone to > not provide an environment that would encourage a company to contemplate > having 2000 > Dlink routers out there with statically assigned IP addresses, but instead > force them > to contemplate 2000 IOS firewalls with a much more expensive, yet remotely > manageable, > setup. > > Ted > > _______________________________________________ > 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 > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From Paul_Vixie at isc.org Thu May 31 19:42:50 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Thu, 31 May 2007 23:42:50 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Thu, 31 May 2007 23:04:24 +0100." <465F4668.9030302@spaghetti.zurich.ibm.com> References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <20070530215313.GA53938@ussenterprise.ufp.org> <20070531215244.GA43143@ussenterprise.ufp.org> <465F4668.9030302@spaghetti.zurich.ibm.com> Message-ID: <8432.1180654970@sa.vix.com> > Don't complain when you didn't try to do anything about it yourself. the last thing i remember from that ietf thing, before i woke up naked in a ditch outside albuquerque, was somebody shouting, "shut up, sit down, that topic has been discussed to death, we reached consensus, we're moving on." from your instructions above, i can't tell whether that means i get to complain, or not. plz advise. From heather.schiller at verizonbusiness.com Thu May 31 19:45:17 2007 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Thu, 31 May 2007 23:45:17 +0000 (GMT) Subject: [ppml] rubber/road In-Reply-To: References: Message-ID: On Thu, 31 May 2007, Ted Mittelstaedt wrote: > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> Jeroen Massar >> Sent: Thursday, May 31, 2007 3:48 PM >> To: Randy Bush >> Cc: Public Policy Mailing List >> Subject: Re: [ppml] rubber/road >> > >>> how much will it cost me in two years? >> >> The amount that is the most of either your IPv4 or the IPv6 one. >> See a couple of days back where somebody disclosed that. >> > > In 2 years a policy could be submitted and > approved that would radically raise prices on the IPv6 block and > require you to pay for both blocks. As long as both allocations ARIN fees are NOT set by the public policy process. ARIN members DO elect the Board of Trustees who set the fee structure and could ask potential board memebers what the think of the issue. The community CAN make suggestions or requests.. I guess if they are going to do it, ppml will likely be the place, but that doesn't make it the right place. It's the Public Policy mailing list. There is the ARIN-discuss mailing list, where fee structure is actually an appropriate topic: arin-discuss at arin.net Open to ARIN members only. Provides a forum for the member community to discuss ARIN-specific issues such as fee structures and internal policies. > (IPv4 and IPv6) are separate, the fear of getting jacked over in > the future is a real possibility. > Why don't you live in fear of getting 'jacked' on v4? The same people who set the fees for v6 are the ones who set the fees for v4. > > this is why I suggested a while ago that IPv6 automatically be allocated > to all paying IPv4 holders. If the IP registration fee was a lump > sum that covered both IPv6 and IPv4 allocations, it would be more > difficult down the road for a price raise on IPv6 to get through. > (Since that would not exist as a separate 'product' of a RIR) > You are combining 2 issues that aren't necesarrily related, fees and allocation policy. The billing structure for v4/v6 doesn't change the merits of an allocation policy of everyone who has v4 today automagically get v6. BoT could change the fee structure to have a combined v6/v4 fee based on organization so that the fee is reduced, but I still wouldn't want to see a 'if you have v4, here's your v6' policy. > > Ted > _______________________________________________ > 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 Thu May 31 19:26:04 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 31 May 2007 18:26:04 -0500 Subject: [ppml] rubber/road References: Message-ID: <06ce01c7a3de$9888d540$493816ac@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" >>The amount that is the most of either your IPv4 or the IPv6 one. >>See a couple of days back where somebody disclosed that. > > In 2 years a policy could be submitted and approved that would > radically raise prices on the IPv6 block and require you to pay > for both blocks. Fees are decided by the Board and the members, not policy. Reportedly, the waiver is being replaced with (what appears to be) a permanent directive that folks will pay the greater of their v4 and v6 fees, not both. That has the effect, for the forseeable future, that everyone will get v6 free just by asking for it. Obviously, nobody can predict what IPv6 fees will look like several years from now, just like we can't predict what IPv4 fees will look like; it's a safe bet that v6 will stay cheaper than v4, though, particularly after v4 exhaustion hits. > As long as both allocations (IPv4 and IPv6) are separate, the > fear of getting jacked over in the future is a real possibility. That's up to the members, and the easiest way to prevent being "jacked over" is to become a member and vote accordingly. Given the Board's recent resolution, though, it's hard to imagine they'll "jack" people adoptiong v6; that's contrary to the community's interests. If anyone is going to get "jacked", it's people who don't. > this is why I suggested a while ago that IPv6 automatically > be allocated to all paying IPv4 holders. That's a different matter and has been responded to already; please resurrect that thread if you want to continue it instead of hijacking others. 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 tedm at ipinc.net Thu May 31 20:12:27 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 31 May 2007 17:12:27 -0700 Subject: [ppml] rubber/road In-Reply-To: <465F548F.8080005@spaghetti.zurich.ibm.com> Message-ID: >-----Original Message----- >From: Jeroen Massar [mailto:jeroen at unfix.org] >Sent: Thursday, May 31, 2007 4:05 PM >To: Ted Mittelstaedt >Cc: Randy Bush; Public Policy Mailing List >Subject: Re: [ppml] rubber/road > > >Ted Mittelstaedt wrote: >[..] >> In 2 years a policy could be submitted and >> approved that would radically raise prices on the IPv6 block and >> require you to pay for both blocks. As long as both allocations >> (IPv4 and IPv6) are separate, the fear of getting jacked over in >> the future is a real possibility. > >My magic crystal ball tells me that IPv4 address space will become >pricey, as that is the resource running out, not IPv6 space. > >You can make all kinds of weird assumptions about the future, one >thing is sure: IPv4 address space won't be available anymore from the >RIRs in a couple of years. The blackmarket will have it for you though. > Once IPv4 space is no longer needed for routing on the Internet, if the fees for IPv6 are practically nothing, how exactly is ARIN going to stay in business? Selling peat? Ted From schiller at uu.net Thu May 31 20:17:06 2007 From: schiller at uu.net (Jason Schiller) Date: Thu, 31 May 2007 20:17:06 -0400 (EDT) Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: Message-ID: Kevin, how about a possible middle ground: 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, c. whenever ARIN has cause to believe that the justification previously used is no longer valid, or d. if an orgization has not requested new resources within one year of their last reques, ARIN may audit only the most recent allocation or assignment. Point c addresses Kevin's concern about the justification changing. Point d returns some of the origional flexibility of the policy to allow ARIN to conduct an audit. This can help limit abuse by allowing followup for orgizations that will not likely need additional resources. It also minamizes the amount of pain placed on large orgizations by limiting the audit to only the most recently allocated or assigned block. __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Mon, 30 Apr 2007, Kevin - Your.Org wrote: > Date: Mon, 30 Apr 2007 18:19:03 -0500 > From: Kevin - Your.Org > To: Public Policy Mailing List , policy at arin.net > Subject: Re: [ppml] Revised Policy Proposal Resource Reclamation > > > On Apr 30, 2007, at 3:26 PM, Owen DeLong wrote: > > 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. > > > I'm fine with A and B, but I can't say I support clause C in there as > it's written. While I don't think anyone at ARIN is malicious or > would conduct reviews unnecessarily, this strikes me as a blank check > to get an undefined "audit" every year that would require furnishing > arbitrary amounts of paperwork to comply. > > Getting paperwork and justification materials together when > requesting additional space is a predictable cost that can be planned > for in advance, and argued that it's necessary for business expansion > or whatever. More space = more revenue, so it's an investment. And, > the worst case that can happen there is you walk away no worse off > than you started, if the expenses/time required exceed what it's > worth to you. Especially for a small business where regular > allocation requests aren't made, these costs can be significant. > > A random inspection is at least as much effort, more risk (you risk > losing what you already have if you're unable to satisfy whatever > undocumented requirements there are for this) so you're probably > going to have to invest more time/money in making sure you get it > right, and a money hole in terms of what you get out of it. > > I can only see three reasons why an audit would need to take place. > You're asking for more space(you initiate this, you're planning for > it in advance, and you can walk away if you get in over your head), > you lied on your last application(all you would have to do is prove > you didn't lie), or whatever justification you used in a previous > application doesn't apply anymore(you've downsized and you really > should be giving space back.) Are there any other reasons why an > audit should take place, other than "because someone felt like it"? > If not, spell that out. > > I'd support: > > 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. whenever ARIN has cause to believe the justification for the > resources no longer exists. > > Along with some kind of definition of exactly what a review entails, > how much time you have to respond to one, can it be appealed, etc. As > your proposal stands, it seems like ARIN can request arbitrary > amounts of paperwork > > While I understand that several people's interpretations of the > existing policy already gives ARIN the right to do this now, if we're > going to enumerate this policy specifically, don't turn it into the > ability to audit every organization every year without cause, with no > definition of what an audit even is, how the procedure is supposed to > work, or why you can get audited. > > -- Kevin > > _______________________________________________ > 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 tedm at ipinc.net Thu May 31 20:17:29 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 31 May 2007 17:17:29 -0700 Subject: [ppml] rubber/road In-Reply-To: Message-ID: >-----Original Message----- >From: Heather Schiller [mailto:heather.schiller at verizonbusiness.com] >Sent: Thursday, May 31, 2007 4:45 PM >To: Ted Mittelstaedt >Cc: Public Policy Mailing List >Subject: Re: [ppml] rubber/road > > > > >On Thu, 31 May 2007, Ted Mittelstaedt wrote: >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >>> Jeroen Massar >>> Sent: Thursday, May 31, 2007 3:48 PM >>> To: Randy Bush >>> Cc: Public Policy Mailing List >>> Subject: Re: [ppml] rubber/road >>> >> >>>> how much will it cost me in two years? >>> >>> The amount that is the most of either your IPv4 or the IPv6 one. >>> See a couple of days back where somebody disclosed that. >>> >> >> In 2 years a policy could be submitted and >> approved that would radically raise prices on the IPv6 block and >> require you to pay for both blocks. As long as both allocations > > > >ARIN fees are NOT set by the public policy process. Totally beside the point. OK you are right, happy now? I'll adjust it to: "...In 2 years the Board of Trustees who set the fee structure could radically raise prices on the IPv6 block..." > >Why don't you live in fear of getting 'jacked' on v4? Who said I didn't? ;-) >The same people who >set the fees for v6 are the ones who set the fees for v4. > >> >> this is why I suggested a while ago that IPv6 automatically be allocated >> to all paying IPv4 holders. If the IP registration fee was a lump >> sum that covered both IPv6 and IPv4 allocations, it would be more >> difficult down the road for a price raise on IPv6 to get through. >> (Since that would not exist as a separate 'product' of a RIR) >> > >You are combining 2 issues that aren't necesarrily related, fees and >allocation policy. The billing structure for v4/v6 doesn't change the >merits of an allocation policy of everyone who has v4 today automagically >get v6. BoT could change the fee structure to have a combined v6/v4 fee >based on organization so that the fee is reduced, but I still wouldn't >want to see a 'if you have v4, here's your v6' policy. > It's going to be a moot issue anyway eventually. When the day comes that nobody wants IPv4 anymore, then IPv6 will BECOME plain old "IP". So, despite all your kicking and screaming, one day we WILL have a "if you have v4, here's your v6" "policy" Kind of like if I have CAT-5 Ethernet, I automatically "have" 10Base2 ethernet if I want to go pick an old thinnet spool out of someones garbage dump. Ted From tedm at ipinc.net Thu May 31 20:23:45 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 31 May 2007 17:23:45 -0700 Subject: [ppml] rubber/road In-Reply-To: <06ce01c7a3de$9888d540$493816ac@atlanta.polycom.com> Message-ID: >-----Original Message----- >From: Stephen Sprunk [mailto:stephen at sprunk.org] >Sent: Thursday, May 31, 2007 4:26 PM >To: Ted Mittelstaedt; Jeroen Massar; Randy Bush >Cc: Public Policy Mailing List >Subject: Re: [ppml] rubber/road > > >Thus spake "Ted Mittelstaedt" >>>The amount that is the most of either your IPv4 or the IPv6 one. >>>See a couple of days back where somebody disclosed that. >> >> In 2 years a policy could be submitted and approved that would >> radically raise prices on the IPv6 block and require you to pay >> for both blocks. > >Fees are decided by the Board and the members, not policy. > >Reportedly, the waiver is being replaced with (what appears to be) a >permanent directive that folks will pay the greater of their v4 >and v6 fees, >not both. That has the effect, for the forseeable future, that everyone >will get v6 free just by asking for it. > >Obviously, nobody can predict what IPv6 fees will look like several years >from now, just like we can't predict what IPv4 fees will look like; it's a >safe bet that v6 will stay cheaper than v4, though, particularly after v4 >exhaustion hits. > I assume you know this depends on the assumption that all non-paying IPv4 legacy holders will start paying the RIRs for IPv6 allocations in that way we can spread the costs around more. If that was not the case for some reason, then it would be impossible for v6 to stay cheaper than v4, unless that is, the RIR's costs for niceties like heat, light, office space, labor, etc. were to somehow decrease. Nobody will pay for v4 once v6 has taken hold, in that case then v6 prices must rise unless cost to administrate numbering goes down, somehow. >> As long as both allocations (IPv4 and IPv6) are separate, the >> fear of getting jacked over in the future is a real possibility. > >That's up to the members, and the easiest way to prevent being >"jacked over" >is to become a member and vote accordingly. Given the Board's recent >resolution, though, it's hard to imagine they'll "jack" people >adoptiong v6; >that's contrary to the community's interests. For right now, because we want IPv6 takeup. But, once everyone has taken IPv6 up, then we will want to continue to fund the administration of IP addresses, eh? At that time it will be in our interests to do so, and obtain funding for it, eh? Or is there some magic feature about IPv6 I have missed that makes it a lot cheaper to administer, once everyone has switched over to it? Ted From tedm at ipinc.net Thu May 31 21:00:19 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 31 May 2007 18:00:19 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <1070531191229.386B-100000@Ives.egh.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >John Santos >Sent: Thursday, May 31, 2007 4:39 PM >To: ppml at arin.net >Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks > > > >This is completely wrong. In Leroy's scenario, his company does not >own and does not manage the 2000 firewalls. Those belong to his >customers. He is not providing a soup-to-nuts internet service to >those customers. He is providing one specific service on one (or a >small) number of specific ports, from one (or a small number of specific) >servers. The *CUSTOMER* has to open the *CUSTOMER'S* firewall to >those specific ports and services in order to utilize Leroy's service. > >It is the 2000 customers who would have to pay the cost. You and I both know this but Leroy conveniently did not include this. Because, of course, it means that it's no longer monstorously unfair to Leroy's company. Just a little unfair. And life is full of little unfairnesses. >It may be >small for each, but its cumulative, and will certainly generating lots >of support calls back to Leroy's company. > Sorry, I had to renumber more customers than that when MCI pulled out of North America and took their blocks with them, I have no sympathy. And we are NOT ACME giant ISP, either. We used those support calls to do quite a lot of checking of customer settings and we found lots of problems that we corrected - such as people using old DNS names of servers long since decomissioned - which would have generated support calls from those customers eventually anyhow - and probably when they were much more frustrated and ready to quit. We also got a rare window into customer networks and managed to make a number of product sales as a result of discovered opportunities. There are ways to manage a transition, even with as large a set as 2000 customers. Sitting around whining about it and complaining to ARIN isn't the way to do it. The only scenario with any believability is if Leroy wanted to reserve the right to threaten his current service provider with immediate disconnection (thereby losing the numbers they allocated to him) because he got the proverbial hair up his arse or some such. Sure, it happens. Legal vehicles like suing the provider for breach of contract are better for the community and more effective than looking like an ass yipping that your going to find some other provider unless they do what you want. Most of the time they are going to call your bluff anyway - you actually have to disconnect for them to pay attention. >My company is in a similar situation to Leroy's customers. We have an >external mail filtering service. Our published MX records point to >the service, and they then forward the (filtered for spam, viruses, >RBL, etc.) mail to us, so we have had to open up our firewall to SMTP >from their specific IP addresses. We are certainly *not* going to let >them manage our firewalls for us, nor are we going to willy-nilly change >our firewall rules on their request without minimally verifying the >origin of the request (a support call to them.) You pay them. They get money for you. They choose to renumber, they then choose to use some of this money to handle your support call. If you are paying them such a small amount every month for filtering that they cannot answer 1 5 minute call from you in a month, then you get what you deserve (a busy signal) and they get what they deserve (you going away to someone else) > >If they were to start changing IP addresses frequently, we would start >looking for a new service provider. > OK, so what your saying as I understand it is that you have such a low regard for the knowledge of the admins running your filtering service, that you do not think they haven't thought of this already, and taken contractual steps with their own ISP so that this wouldn't happen - yet you are still using them? Facinating! >This is an *extremely* unlevel playing field, since ACME GIANT ASP, >INC. (which is many times the size of Leroy's company), could easily >justify an allocation, and thus could promise their customers that >their IP addresses and firewall rule would never change. > MCI -WAS- an ACME GIANT ASP INC. - yet, somehow they couldn't guarentee it for their customers, either. >Of course, Leroy could game the system and provide each of his customers >with a single, unique IP address (thus requiring 8 class C's) and >then forward them all to the same handfull of servers at his firewalls. > I do not see that this is "gaming the system" It is, in fact, a rather legitimate use of IP. IP addresses are just numbers after all. There is really no such thing as a shortage of numbers - I can put you into a corner and tell you to start counting and you could spend the rest of your life doing it. No shortage there! And the entire point of IPv6 is to have so many numbers that you aren't going to have shortages. >So is it better for the overburdened routers to route to one Class C >(what Leroy actually requires), or to 8 of them? (Especially given >there is no guarantee the 8 would be contiguous and thus could be >treated as a single /21 for routing purposes.) > If Leroy is moral, he will have the decency to give his customers some sort of reassurance of reliability by becoming multihomed, getting an AS, and getting a portable block the normal way. If I'm one of his customers I certainly have the right after paying Leroy to expect that his service is going to be redundant. If Leroy is criminal, this discussion is pointless, because Leroy is just going to do whatever is cheapest for him, and damn the rest of us. ARIN and numbering allocations in general cannot survive in their present form if a significant percentage of admins decide to be criminal. That is what happened to the Domain Name System and as a result of it, DNS had to be completely changed around so as to make offenses things that real police could actually go after. And even so, they still have a huge problem with squatting. Your basically arguing here that people should have the freedom to put a car on the road with green brake lights because they think it looks pretty, and drive 100Mph on every road, in the LH lane. IP numbering is a shared resource like a road. You have to do things like putting red brake lights on the ass end of your car because it helps other people and the roads would not work if everyone put whatever color they wanted on brake lights. Just because it's not obvious that someone is breaking the rules doesen't mean that it isn't possible to catch them - and if we have enough rule breaking, your going to see the cops coming. I don't want that and I hope you don't either. Ted From marla.azinger at frontiercorp.com Thu May 31 21:01:35 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 31 May 2007 21:01:35 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F8FB@nyrofcs2ke2k01.corp.pvt> Leo and Jeroen- I am a little surprised at Leo's comment. Mainly because last July I started attending IETF conferences on behalf of the ARIN AC (and he is on the AC). Granted AC is different from the BOT but the BOT knows and supports the new attempt to participate with IETF by sending an AC member to the IETF meetigs. The intent of my attendance is to help create a working relationship between IETF and the ARIN RIR thus enabling both address policy and routing RFC's to work in unison and not in opposition. Granted, I am heavily focused on the IPv6 arena and that is what my last briefing at the ARIN conference covered. I suppose I should take blame for having a boring presentation thus people missed the point about how I am attending IETF's and actively participating and working on those very things that people feel were "dropped". As we all know there has been a very fuzzy line and cross over between routing and address policy. There probably always will be, and the thing to do here as Jeroen pointed out is to work with it. So that is why you will find me at future IETF's as an ARIN AC Member. Cheers! Marla Azinger Frontier Communications ARIN AC Chair -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jeroen Massar Sent: Thursday, May 31, 2007 3:04 PM To: Leo Bicknell Cc: 'ARIN PPML' Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again Leo Bicknell wrote: [..] > I think the ARIN board needs to issue a second statement aimed at the > IETF: I think that instead of complaining, you should try to participate in the IETF process, which, like the RIR processes, are completely open. Several people from the IETF have extended their arms already several times in the direction of the RIR's and NANOG, there have even been debates about this. That you did not participate in any of these things in the last 10 years, tsja... Don't complain when you didn't try to do anything about it yourself. Greets, Jeroen From alh-ietf at tndh.net Thu May 31 21:17:01 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 31 May 2007 18:17:01 -0700 Subject: [ppml] Keeping the story straight In-Reply-To: References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> <1f8101c7a3c7$9c246a00$d46d3e00$@net> Message-ID: <00b801c7a3ea$8f29bb20$ad7d3160$@net> Heather Schiller wrote: > > ..... > > > > Somebody needs to figure out the real story, then try to keep it > straight. > > Tony > > > > I can't tell from your email if you want: > - ARIN to guarantee routability > - not make a formal statement on routability (thus implying anything or > nothing) > - You want ARIN/RIR's to declare/refine their function/mission > statement > - or you just want to ask a bunch of rhetorical questions to get people > thinking and you may or may not have your own opinion? > > (..and I'm not intending to be snide.. it's just that sometimes email > is a > lousy method of communication and I really can't tell) I was pointing out the difference in attitude, depending on who is arguing what point. On the one hand people take the high-road and say ARIN does not talk about routability, while on the other people want to refuse space to people unless it is 'routed in the public Internet'. I would actually prefer to remove all discussion about routability and just talk about managing the IPv6 pool. People should be able to get a PI block and a ULA-C block, and what they do with those is not ARIN's concern as long as they maintain their membership. It really doesn't matter if people don't think they need both, if the requestor thinks they need it and their membership is current, give it to them. What happens after that is not an ARIN policy concern. The flip-flopping that goes on about routability is what has to stop. If the majority wants to only worry about routed space, I am fine with that, but you can't have it both ways like it is now. Tony From stephen at sprunk.org Thu May 31 21:09:29 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 31 May 2007 20:09:29 -0500 Subject: [ppml] rubber/road References: Message-ID: <076a01c7a3eb$6c247880$493816ac@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" > I assume you know this depends on the assumption that all > non-paying IPv4 legacy holders will start paying the RIRs for > IPv6 allocations in that way we can spread the costs around > more. You assume costs will remain at current levels. However, yes, eventually legacy-holders will need to start paying fees if they want to get direct IPv6 assignments. It remains to be seen if they will within a timeframe that merits discussion today. > If that was not the case for some reason, then it would be > impossible for v6 to stay cheaper than v4, unless that is, the > RIR's costs for niceties like heat, light, office space, labor, etc. > were to somehow decrease. > > Nobody will pay for v4 once v6 has taken hold, in that case then > v6 prices must rise unless cost to administrate numbering goes > down, somehow. If budget shortfalls are predicted, the Board is required to increase revenue (which probably means raising fees, but might mean lowering them) or decrease costs, regardless of what the cause is. That's not necessarily linked to IPv6 deployment or IPv4 becoming worthless, though. There's also no link between those things and the relative fees for IPv6 vs IPv4; the Board could instead decide to raise IPv4 fees faster than IPv6 until people just stop using IPv4 -- there've been a few informal proposals to do exactly that to delay (or even reverse) exhaustion. > Or is there some magic feature about IPv6 I have missed that > makes it a lot cheaper to administer, once everyone has > switched over to it? The "magic" is that we've tried to make IPv6 policy such that the vast majority of orgs will never need more than an initial, minimum-sized block which is somewhere between "trivial to justify" and "automatic". Compare to IPv4, where many orgs have _hundreds_ of blocks and have to come back for more every few months, requiring detailed review by staff. Simply put, IPv6 should require fewer man-hours to handle than IPv4 because the request volume will be lower and the effort per request will be lower. Bad news for ARIN staffers, I suppose, but good news for fees. Some fee adjustment may be necessary for ARIN to keep funding fixed-cost items like servers for WHOIS and DNS, internal systems and tools, meetings, outreach, etc. if the maintenance fees (plus the occasional new assignment fee) for IPv6 won't be enough after IPv4 finally dies, but that won't be "jacking" with anyone -- it'll be necessary to remain solvent, and it's far enough off in any case that it's not productive to try to predict what's going to happen or when. 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 JOHN at egh.com Thu May 31 21:40:41 2007 From: JOHN at egh.com (John Santos) Date: Thu, 31 May 2007 21:40:41 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: Message-ID: <1070531212803.19291A-100000@Ives.egh.com> On Thu, 31 May 2007, Ted Mittelstaedt wrote: > > > >-----Original Message----- > >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > >John Santos > >Sent: Thursday, May 31, 2007 4:39 PM > >To: ppml at arin.net > >Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks > > > > > > > >This is completely wrong. In Leroy's scenario, his company does not > >own and does not manage the 2000 firewalls. Those belong to his > >customers. He is not providing a soup-to-nuts internet service to > >those customers. He is providing one specific service on one (or a > >small) number of specific ports, from one (or a small number of specific) > >servers. The *CUSTOMER* has to open the *CUSTOMER'S* firewall to > >those specific ports and services in order to utilize Leroy's service. > > > >It is the 2000 customers who would have to pay the cost. > > You and I both know this but Leroy conveniently did not include this. > Because, of course, it means that it's no longer monstorously unfair > to Leroy's company. Just a little unfair. And life is full of > little unfairnesses. > > >It may be > >small for each, but its cumulative, and will certainly generating lots > >of support calls back to Leroy's company. > > > > Sorry, I had to renumber more customers than that when MCI pulled out > of North America and took their blocks with them, I have no sympathy. > And we are NOT ACME giant ISP, either. We used those support calls > to do quite a lot of checking of customer settings and we found lots > of problems that we corrected - such as people using old DNS names of > servers long since decomissioned - which would have generated support > calls from those customers eventually anyhow - and probably when they > were much more frustrated and ready to quit. We also got a rare window > into customer networks and managed to make a number of product sales as a > result of discovered opportunities. > > There are ways to manage a transition, even with as large a set as > 2000 customers. Sitting around whining about it and complaining to > ARIN isn't the way to do it. The only scenario with any believability > is if Leroy wanted to reserve the right to threaten his current service > provider with immediate disconnection (thereby losing the numbers they > allocated to him) because he got the proverbial hair up his arse or some > such. > > Sure, it happens. Legal vehicles like suing the provider for breach of > contract are better for the community and more effective than looking > like an ass yipping that your going to find some other provider unless > they do what you want. Most of the time they are going to call your > bluff anyway - you actually have to disconnect for them to pay attention. > > >My company is in a similar situation to Leroy's customers. We have an > >external mail filtering service. Our published MX records point to > >the service, and they then forward the (filtered for spam, viruses, > >RBL, etc.) mail to us, so we have had to open up our firewall to SMTP > >from their specific IP addresses. We are certainly *not* going to let > >them manage our firewalls for us, nor are we going to willy-nilly change > >our firewall rules on their request without minimally verifying the > >origin of the request (a support call to them.) > > You pay them. They get money for you. They choose to renumber, they > then choose to use some of this money to handle your support call. > > If you are paying them such a small amount every month for filtering that > they cannot answer 1 5 minute call from you in a month, then you get what > you deserve (a busy signal) and they get what they deserve (you going away > to someone else) > > > > >If they were to start changing IP addresses frequently, we would start > >looking for a new service provider. > > > > OK, so what your saying as I understand it is that you have such a low > regard for the knowledge of the admins running your filtering service, that > you do not think they haven't thought of this already, and taken > contractual steps with their own ISP so that this wouldn't happen - yet > you are still using them? Facinating! What is it about the word "if" that you don't understand? This has nothing to do with my regard or disregard for their ethics or competence. > > >This is an *extremely* unlevel playing field, since ACME GIANT ASP, > >INC. (which is many times the size of Leroy's company), could easily > >justify an allocation, and thus could promise their customers that > >their IP addresses and firewall rule would never change. > > > > MCI -WAS- an ACME GIANT ASP INC. - yet, somehow they couldn't guarentee > it for their customers, either. > > >Of course, Leroy could game the system and provide each of his customers > >with a single, unique IP address (thus requiring 8 class C's) and > >then forward them all to the same handfull of servers at his firewalls. > > > > I do not see that this is "gaming the system" It is, in fact, a rather > legitimate use of IP. IP addresses are just numbers after all. There is > really no such thing as a shortage of numbers - I can put you into a corner > and tell you to start counting and you could spend the rest of your life > doing > it. No shortage there! And the entire point of IPv6 is to have so many > numbers that you aren't going to have shortages. > No IPv4 address shortage? Then what is everyone whinging on about? > >So is it better for the overburdened routers to route to one Class C > >(what Leroy actually requires), or to 8 of them? (Especially given > >there is no guarantee the 8 would be contiguous and thus could be > >treated as a single /21 for routing purposes.) > > > > If Leroy is moral, he will have the decency to give his customers some > sort of reassurance of reliability by becoming multihomed, getting an > AS, and getting a portable block the normal way. If I'm one of his > customers I certainly have the right after paying Leroy to expect that > his service is going to be redundant. > So he needs 2 /24's (or more realisticly, 2 /25's for his 75 servers.) > If Leroy is criminal, this discussion is pointless, because Leroy is > just going to do whatever is cheapest for him, and damn the rest of us. > > ARIN and numbering allocations in general cannot survive in their present > form if a significant percentage of admins decide to be criminal. That > is what happened to the Domain Name System and as a result of it, DNS > had to be completely changed around so as to make offenses things that > real police could actually go after. And even so, they still have a > huge problem with squatting. > > Your basically arguing here that people should have the freedom to put a > car on the road with green brake lights because they think it looks pretty, > and drive 100Mph on every road, in the LH lane. IP numbering is a shared > resource like a road. You have to do things like putting red brake lights > on > the ass end of your car because it helps other people and the roads would > not work if everyone put whatever color they wanted on brake lights. Where did this come from? All I'm saying is people should be entitled to permanent IP addresses, for as long as they need them, and they shouldn't be required to fake a need for more than they actually need just to get them. > > Just because it's not obvious that someone is > breaking the rules doesen't mean that it isn't possible to catch them - > and if we have enough rule breaking, your going to see the cops coming. > I don't want that and I hope you don't either. Cops? Now your waving cops at me. At worst, this would be a civil issue (breach of contract with ARIN), not a criminal issue. But my point is that the contract with ARIN doesn't promote conservation of number resources by creating artificially high minimums. > > Ted > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From bicknell at ufp.org Thu May 31 21:44:59 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 31 May 2007 21:44:59 -0400 Subject: [ppml] Keeping the story straight In-Reply-To: <00b801c7a3ea$8f29bb20$ad7d3160$@net> References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> <1f8101c7a3c7$9c246a00$d46d3e00$@net> <00b801c7a3ea$8f29bb20$ad7d3160$@net> Message-ID: <20070601014459.GE56377@ussenterprise.ufp.org> In a message written on Thu, May 31, 2007 at 06:17:01PM -0700, Tony Hain wrote: > I was pointing out the difference in attitude, depending on who is arguing > what point. On the one hand people take the high-road and say ARIN does not > talk about routability, while on the other people want to refuse space to > people unless it is 'routed in the public Internet'. I would actually prefer > to remove all discussion about routability and just talk about managing the > IPv6 pool. [snip] > The flip-flopping that goes on about routability is what has to stop. If the > majority wants to only worry about routed space, I am fine with that, but > you can't have it both ways like it is now. I'd counter by asking if it's really flip-flopping? I can't think of many individuals who flip-flop on this issue. There people who think we should never talk about routability. There are people who feel strongly routability is a huge concern, and ARIN should not issue things that are not routable and/or put pressure on the routing system. My feeling is these camps are of relatively similar size, so the meetings tend to be split 50/50 (60/40, whatever). That does make the group as a whole look like it flip-flops.... Unfortunately, without getting one side to give up, I'm not sure how you fix it. -- 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 bicknell at ufp.org Thu May 31 22:01:56 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 31 May 2007 22:01:56 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F8FB@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A0272F8FB@nyrofcs2ke2k01.corp.pvt> Message-ID: <20070601020156.GF56377@ussenterprise.ufp.org> In a message written on Thu, May 31, 2007 at 09:01:35PM -0400, Azinger, Marla wrote: > I am a little surprised at Leo's comment. Mainly because last > July I started attending IETF conferences on behalf of the ARIN AC > (and he is on the AC). I applaud your efforts and willingness to attend the IETF meetings and try and make progress. I absolutely think the solution needs to be done in the IETF, and not ad-hoc by vendors or tacked on by the RIR or operator community. Those who have the time and skill should attend and contribute. However, I'm worried that the IETF needs to shake things up a bit. I had to go back to the transcript (http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html#anchor_12), but here's my worry. The various working groups are "working on": CIDR Boundary, Aggregation Slicing, Metro, Map and Encap, LISP, eFIT, Shim6 If you believe Geoff Huston's latest information (http://www.potaroo.net/tools/ipv4/) 13-Mar-2010 is the date. So we have somewhere between 2 and 3 years before there's likely to be a huge upswell in IPv6 deployment (maybe shorter). If I were at the IETF, or for that matter a vendor, I'd feel some pressure to step it up, hold double meetings, and get this problem solved ASAP. Otherwise my prediction is we run out of IPv4 space, people start using IPv6 like crazy, the operators make up the rules as they go along, and by the time the dust settles no one will see a point in any of the above solutions because "it's up and working" and none will see the light of day, ever. Once someone has their PI prefix in the global table do you think they will care of Shim6 ever comes to be? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Thu May 31 22:21:30 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 31 May 2007 19:21:30 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: References: Message-ID: <1CDCBAA6-4838-4981-905F-D7AB8826E4A3@delong.com> On May 31, 2007, at 6:00 PM, Ted Mittelstaedt wrote: > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >> Behalf Of >> John Santos >> Sent: Thursday, May 31, 2007 4:39 PM >> To: ppml at arin.net >> Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks >> >> >> >> This is completely wrong. In Leroy's scenario, his company does not >> own and does not manage the 2000 firewalls. Those belong to his >> customers. He is not providing a soup-to-nuts internet service to >> those customers. He is providing one specific service on one (or a >> small) number of specific ports, from one (or a small number of >> specific) >> servers. The *CUSTOMER* has to open the *CUSTOMER'S* firewall to >> those specific ports and services in order to utilize Leroy's >> service. >> >> It is the 2000 customers who would have to pay the cost. > > You and I both know this but Leroy conveniently did not include this. > Because, of course, it means that it's no longer monstorously unfair > to Leroy's company. Just a little unfair. And life is full of > little unfairnesses. > No, actually, it is still monstrously unfair to Leroy's company _BECAUSE_ it puts him at a significant competitive disadvantage relative to other organizations that are either large or unethical enough to get assignments under current policy. > Sorry, I had to renumber more customers than that when MCI pulled out > of North America and took their blocks with them, I have no sympathy. > And we are NOT ACME giant ISP, either. We used those support calls > to do quite a lot of checking of customer settings and we found lots > of problems that we corrected - such as people using old DNS names of > servers long since decomissioned - which would have generated support > calls from those customers eventually anyhow - and probably when they > were much more frustrated and ready to quit. We also got a rare > window > into customer networks and managed to make a number of product > sales as a > result of discovered opportunities. > And you'd like to repeat this on an annual basis? Because, that's about how often bandwidth pricing changes make changing providers attractive if you want to stay competitive on cost. I'm betting that if you don't have PI addresses, you aren't changing providers annually. Of course, there's the old standby of get your addresses from some really cheap connection that you don't actually use for bandwidth, then advertise those chunks on your bandwidth de jour, but, at that point, the routing table is carrying your routes anyway, and, the internet isn't gaining anything from your PA space, so, we might as well give you PI, right? > There are ways to manage a transition, even with as large a set as > 2000 customers. Sitting around whining about it and complaining to > ARIN isn't the way to do it. The only scenario with any believability > is if Leroy wanted to reserve the right to threaten his current > service > provider with immediate disconnection (thereby losing the numbers they > allocated to him) because he got the proverbial hair up his arse or > some > such. > There are ways to live years with HIV, too. That doesn't mean it's an activity you want to engage in if you don't have to. Nobody is sitting around whining. We're trying to change policy to make it more reasonable and more even handed for smaller organizations. [snip] > >> >> If they were to start changing IP addresses frequently, we would >> start >> looking for a new service provider. >> > > OK, so what your saying as I understand it is that you have such a low > regard for the knowledge of the admins running your filtering > service, that > you do not think they haven't thought of this already, and taken > contractual steps with their own ISP so that this wouldn't happen - > yet > you are still using them? Facinating! > No, what he's saying is that they should be able to switch ISPs at will without affecting his service. Their choice of ISP and any difficulties they have should be transparent to him as a customer. No amount of knowledge can overcome the fact that if you are using PA addresses, you can't switch ISPs without renumbering. No amount of knowledge can make renumbering a service transparent to your customers. > > MCI -WAS- an ACME GIANT ASP INC. - yet, somehow they couldn't > guarentee > it for their customers, either. > Um, no. MCI was an ACME GIANT ISP INC. Not an ASP. There's a rather large difference between an ISP and an ASP. MCI didn't renumber... They took their addresses with them when they left. Sure, that affected their former customers, but, it didn't affect their current customers. >> Of course, Leroy could game the system and provide each of his >> customers >> with a single, unique IP address (thus requiring 8 class C's) and >> then forward them all to the same handfull of servers at his >> firewalls. >> > > I do not see that this is "gaming the system" It is, in fact, a > rather > legitimate use of IP. IP addresses are just numbers after all. > There is > really no such thing as a shortage of numbers - I can put you into > a corner > and tell you to start counting and you could spend the rest of your > life > doing > it. No shortage there! And the entire point of IPv6 is to have so > many > numbers that you aren't going to have shortages. > Yes, but, since the IPv6 numbers don't currently talk to the internet in a meaningful way, we're stuck with the rather finite set of IPv4 numbers. I think most on this list would agree that the stated usage of IP addresses does constitute gaming the system if it is done solely for the purpose of consuming enough addresses to justify a larger block in order to qualify under current policy. >> So is it better for the overburdened routers to route to one Class C >> (what Leroy actually requires), or to 8 of them? (Especially given >> there is no guarantee the 8 would be contiguous and thus could be >> treated as a single /21 for routing purposes.) >> > > If Leroy is moral, he will have the decency to give his customers some > sort of reassurance of reliability by becoming multihomed, getting an > AS, and getting a portable block the normal way. If I'm one of his > customers I certainly have the right after paying Leroy to expect that > his service is going to be redundant. > If Leroy is moral, he would prefer to do that with a portable block of the minimum size he needs so he is not consuming addresses for the sake of consumption. However, current policy requires Leroy to use a /22 in order to do what you state, even though he can do it perfectly well in a /24. > If Leroy is criminal, this discussion is pointless, because Leroy is > just going to do whatever is cheapest for him, and damn the rest of > us. > If Leroy is moral, but, pragmatic, he'll potentially find a legitimate way to multiply his IP usage by some needed number (8, for example), and then apply for a block of the size required in order to get one, but, Leroy, being moral will regret having to do so and will continue to believe that policy should be changed to facilitate doing this honestly without the excess address wastage. > Your basically arguing here that people should have the freedom to > put a > car on the road with green brake lights because they think it looks > pretty, > and drive 100Mph on every road, in the LH lane. IP numbering is a > shared > resource like a road. You have to do things like putting red brake > lights > on > the ass end of your car because it helps other people and the roads > would > not work if everyone put whatever color they wanted on brake lights. > No, actually, he's arguing that people should be allowed to put smaller cars on the road because they are more fuel efficient and that they shouldn't be prohibited just because they weren't made by Ford, GM, or Toyota. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From randy at psg.com Thu May 31 23:12:17 2007 From: randy at psg.com (Randy Bush) Date: Thu, 31 May 2007 20:12:17 -0700 Subject: [ppml] rubber/road In-Reply-To: <465F5095.40209@spaghetti.zurich.ibm.com> References: <465F4AD8.6070104@psg.com> <465F5095.40209@spaghetti.zurich.ibm.com> Message-ID: <465F8E91.8000603@psg.com> >> let's say i wanted to do it in whatever is the current fashion for >> correctly. do i get two /32s from arin? > Can you justify for the need of a /32 at each site, if so, then why not. no. and the why not would be cost as opposed to pa and hole punching. > If you can't justify a /32 each, you might want to try justifying a > single /32. The side effect, if you split that up into chunks of /48's > or /40's you might run into filters, and that is not so weird as > (afaik) the policy explicitly states you have to announce the > aggregate. these are two racks, no backbone between. >> two /48s? > If you can justify that, why not. They definitely are 2 sites, so a > /48 each sounds logical. It is the minimum allocation size. > Routingwise these /48's should get through. i am told that they actually will not. >> how much will that cost today? > As you already have IPv4 space (afaik, though maybe for you that is > legacy stuff you don't pay for?) nothing, as the fees are waved. v4 is legacy. so do i pay for v6? >> how much will it cost me in two years? > The amount that is the most of either your IPv4 or the IPv6 one. > See a couple of days back where somebody disclosed that. or whatever they choose to jack me for in two years. i think i will stick to pa. randy