Re: "Leasing" of space via non-connectivity providers
On Feb 5, 2011, at 8:40 PM, bmanning@vacation.karoshi.com wrote:
On Sat, Feb 05, 2011 at 09:12:53PM +0000, John Curran wrote:
RFC 2050 is the document which provides the registry system framework. Jon Postel is an author of same, as well as a founder of ARIN.
yup.. i was there when it was written.
Excellent; it could prove helpful in clarifying things.
It does not talk to address space allocated to entities from the IANA or other registries prior to the RIRs existance.
Is it your belief that Jon did not intend RFC 2050 to apply to the existing allocations maintained by the three regional registries in existence at the time (InterNIC, RIPE NCC and APNIC)? I imagine that is plausible, but it would run contrary to the language which states that assignments should be viewed as loans and "to this end, ISPs should have documented justification available for each assignment. The regional registry may, at any time, ask for this information. If the information is not available, future allocations may be impacted. In extreme cases, existing loans may be impacted." I'm having trouble understanding how *existing* allocations could be impacted if existing registry allocations were not covered. Or are you suggesting that RFC 2050 applies, but there is a select set of ISP allocations that were outside of InterNIC, APNIC, and RIPE NCC to which special handling is applied? Further, RFC 2050 states "The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR." Even one were to hypothecate some type of address space that could be the *source* of a transfer due to a mystical handling status, how could any party be the *recipient* of such without demonstrating need to one of the regional registries per the second referenced text? Is this also a case where it was meant to exclude some special parties but just did not get stated in the actual RFC 2050 text? Thanks! /John John Curran President and CEO ARIN
John, On Feb 5, 2011, at 7:33 PM, John Curran wrote:
It does not talk to address space allocated to entities from the IANA or other registries prior to the RIRs existance. Is it your belief that Jon did not intend RFC 2050 to apply to the existing allocations maintained by the three regional registries in existence at the time (InterNIC, RIPE NCC and APNIC)?
Last I checked, the other four authors of RFC 2050 are still alive. Why not ask them?
Further, RFC 2050 states "The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR."
I'm curious: when HP acquired the assets of Compaq (or when Compaq acquired the assets of Digital), is it your position that HP (or Compaq) "met the same criteria as if they were requesting an IP address directly from the IR." for 16.0.0.0/8? Regards, -drc
On Feb 6, 2011, at 1:25 AM, David Conrad wrote:
Last I checked, the other four authors of RFC 2050 are still alive. Why not ask them?
Bill indicated he "was there when it was written" in reference to Jon being an author, and I was inquiring to whether he had any knowledge of Jon's intent that he could share. If you have knowledge of Jon's intent, or any insight on why RFC 2050 includes the existing allocations if the intent was actually to leave it vague with respect to same, that also would be helpful.
Further, RFC 2050 states "The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR."
I'm curious: when HP acquired the assets of Compaq (or when Compaq acquired the assets of Digital), is it your position that HP (or Compaq) "met the same criteria as if they were requesting an IP address directly from the IR." for 16.0.0.0/8?
The handling of general case varies based on the community developed policy over the years, currently as specified by NRPM 8.2 (M&A Transfer) in https://www.arin.net/policy/nrpm.html. There's a Change Log on the page if you want to track the policy at any given point in time. I can not comment on any specific transfer request, but will note that at one time the M&A transfer policy allowed transfer of all held number resources without justification of need as long as the entire entity was involved, but at this point the policy indicates that: "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return, aggregate, or reclaim resources as appropriate via the processes outlined in current ARIN policy (for example, sections 4.6, 4.7, or 12 of the NRPM)." FYI, /John John Curran President and CEO ARIN
John, On Feb 5, 2011, at 8:47 PM, John Curran wrote:
On Feb 6, 2011, at 1:25 AM, David Conrad wrote:
Last I checked, the other four authors of RFC 2050 are still alive. Why not ask them? Bill indicated he "was there when it was written" in reference to Jon being an author, and I was inquiring to whether he had any knowledge of Jon's intent that he could share. If you have knowledge of Jon's intent, or any insight on why RFC 2050 includes the existing allocations if the intent was actually to leave it vague with respect to same, that also would be helpful.
As you're aware, RFC 2050 was a group effort, so focusing on Jon's intent seems questionable particularly given he sadly isn't around to provide corrections. My recollection is that all of the authors recognized that attempting to deal with what is now known as legacy space was _extremely_ controversial and was wildly unlikely to have reached any consensus, particularly in the context of how the IETF works and the then ongoing battles regarding CIDR deployment and its implications. Instead, we consciously focused on merely trying to document the then current practice for allocations and assignments. Even that turned out to be a prolonged nightmare, especially trying to get it through the IESG (which discouraged further attempts at trying to use the IETF to derive addressing policy). In other words, since RFC 2050 merely attempted to document then current practices, it intentionally did not address (pun intended) allocations made prior to the establishment of those practices directly. Rather, it merely noted that future allocations or assignments would take existing holdings into account. With regards to specific language, you reference section 2.1.1. You'll note that this is in a section talking about guidelines for how ISPs should deal with address space. It is saying ISPs should treat assignments to their customers like loans. Section 2.1.3 is talking about two different things as indicated by the terminology used. The "future _allocations_ may be impacted" is talking about allocations made from the RIR to the ISP. The "existing _loans_ may be impacted" is saying the RIR could ignore assignments the ISP has made to its customers (making it a bit difficult for the ISP to get new space).
Further, RFC 2050 states "The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR."
I'm curious: when HP acquired the assets of Compaq (or when Compaq acquired the assets of Digital), is it your position that HP (or Compaq) "met the same criteria as if they were requesting an IP address directly from the IR." for 16.0.0.0/8?
The handling of general case varies based on the community developed policy over the years, [...] but will note that at one time the M&A transfer policy allowed transfer of all held number resources without justification of need as long as the entire entity was involved, but at this point the policy indicates that [....]
So, if you believe ARIN policy applies to all space, you're saying that ARIN at one time violated the section of RFC 2050 you quoted and that later, ARIN changed that policy. This sort of policy evolution is exactly what was envisioned when we wrote RFC 2050. We assumed policies would change over time, and as such RFC 2050 was merely documenting the current practice as it was in 1996. This is why I always find your referencing 2050 as if it is sacred text curious. In thinking about this, since RFC 2050 was focused on IPv4 allocation policy and there is no more IPv4 to allocate, 2050 should probably be moved to historic. Regards, -drc
On Feb 6, 2011, at 2:16 PM, David Conrad wrote:
As you're aware, RFC 2050 was a group effort, so focusing on Jon's intent seems questionable particularly given he sadly isn't around to provide corrections.
While it may have been a group effort, Jon was the IANA.
With regards to specific language, you reference section 2.1.1. You'll note that this is in a section talking about guidelines for how ISPs should deal with address space. It is saying ISPs should treat assignments to their customers like loans. Section 2.1.3 is talking about two different things as indicated by the terminology used. The "future _allocations_ may be impacted" is talking about allocations made from the RIR to the ISP. The "existing _loans_ may be impacted" is saying the RIR could ignore assignments the ISP has made to its customers (making it a bit difficult for the ISP to get new space).
Interesting viewpoint in separating the two, as the full context is: "If the information is not available, future allocations may be impacted. In extreme cases, existing loans may be impacted." Your suggestion that "existing loans may be impacted" means to be ignored for evaluating future allocations does seems a bit superfluous when taken in full context, but obviously must be considered as you are one of the authors. One wonders why it just doesn't repeat "future allocations may be impacted" for the second sentence. Do you have any similar suggestions for how to reinterpret the transfer section, i.e. " The transfer of IP addresses from one party to another must be approved by the regional registries." or "The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR." ?
So, if you believe ARIN policy applies to all space, you're saying that ARIN at one time violated the section of RFC 2050 you quoted and that later, ARIN changed that policy. This sort of policy evolution is exactly what was envisioned when we wrote RFC 2050. We assumed policies would change over time, and as such RFC 2050 was merely documenting the current practice as it was in 1996. This is why I always find your referencing 2050 as if it is sacred text curious.
It's fairly difficult to have a consistent global registry framework that the regional registries operate under unless its actually followed by the regional registries. What would have been best would have been to separate the document into two; one for the overall Internet Registry requirements technically necessary, and then one with the current view on appropriate allocation policy. I wasn't there, so I can't say why the two are combined. In the particular instance you point out, I'm happy to say ARIN is back in alignment with RFC 2050 as written.
In thinking about this, since RFC 2050 was focused on IPv4 allocation policy and there is no more IPv4 to allocate, 2050 should probably be moved to historic.
It certainly would be worth considering revising to maintain the portions which are an inherent technical requirements from IAB/IETF versus those which are a snapshot of registry policy at the time. It also is interesting to consider which forum(s) such an activity should take place in, since it's clear that an overall framework is necessary for the system to keep working globally. /John John Curran President and CEO ARIN
On Feb 6, 2011, at 9:53 AM, John Curran wrote:
Your suggestion that "existing loans may be impacted" means to be ignored for evaluating future allocations does seems a bit superfluous when taken in full context, but obviously must be considered as you are one of the authors.
I believe (it has been 15 years after all) the idea was that if an ISP didn't update the registry with new assignments, the RIR could in extreme cases remove previously submitted reassignment information as punishment (the theory being that this would cause the ISP's customers to take action). Again, this wording is in a section that is discussing sub-delegation guidelines for ISPs who received an allocation from the RIRs. How are you "reinterpreting" section 2.1.3?
Do you have any similar suggestions for how to reinterpret the transfer section, i.e. " The transfer of IP addresses from one party to another must be approved by the regional registries." or "The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR." ?
As opposed to section 2, section 4.7 seems pretty unambiguous to me: it was an attempt by the registries at the time to conserve the remaining IPv4 free pool by disallowing the bypassing of registry allocation restrictions. Do you "reinterpret" it differently?
It certainly would be worth considering revising to maintain the portions which are an inherent technical requirements from IAB/IETF versus those which are a snapshot of registry policy at the time.
I hear Mark McFadden, since he hated his life, was working on 2050bis... :-) More seriously, RFC 2050 was an attempt to document the then current (in 1996) practices for allocating IPv4 addresses. Instead of revising that 15 year old document, I'd think a document that describes the role and responsibilities of the registries in a post-IPv4 free pool world would be much more valuable. My impression is that there is a bit of a disconnect between the folks who go to RIR meetings and the folks who have IP addresses (particularly those folks who received their addresses prior to the existence of the RIRs). Might be useful to remedy this.
It also is interesting to consider which forum(s) such an activity should take place in, since it's clear that an overall framework is necessary for the system to keep working globally.
Yeah, too bad no one set up an organization whose By-Laws and Mission is to coordinate, at an overall level, the global Internet's systems of unique identifiers capable of providing such a forum. Regards, -drc
it is both amusing and horrifying to watch two old dogs argue about details of written rules as if common sense had died in october 1998. what is good for the internet? what is simple? what is pragmatic? if the answer is not simple and obvious, we should go break something else. randy
On Feb 6, 2011, at 7:51 PM, Randy Bush wrote:
it is both amusing and horrifying to watch two old dogs argue about details of written rules as if common sense had died in october 1998. what is good for the internet? what is simple? what is pragmatic? if the answer is not simple and obvious, we should go break something else.
Actually, I'm in full agreement with you: the goal needs to be to keep the Internet running. Alas, I've run a few networks, but that's a few years back, and I'll be the first to admit that my particular graybeard views on what is best for the Internet lacks current operational insights. Also note that, as CEO of ARIN, it is not my role to preempt discussion by proposing solutions, but instead to encourage good discussion of the issues. So, what exactly is broken and needs to be changed? I do know that we can't have the basic premises of the system completely set on a regional basis, but we also have to allow for regional differences in policy since operators face different challenges. While the discussion is ongoing, we're keeping to the principles of aggregation, conservation, and registration, and looking forward to any consensus that emerges from the operator community to change these principles. /John John Curran President and CEO ARIN
So, what exactly is broken and needs to be changed?
the policy making process. we have created a minor industry in telling other people how to run their network. how about no more ipv4 policy proposals and charge $1,000 to file an ipv6 policy proposal? randy
On Feb 7, 2011, at 10:25 AM, Randy Bush wrote:
So, what exactly is broken and needs to be changed?
the policy making process. we have created a minor industry in telling other people how to run their network.
how about no more ipv4 policy proposals and charge $1,000 to file an ipv6 policy proposal?
randy
If you believe this is a good idea, submit it to ARIN Consultation and Suggestion Process. If not, then I'm willing to bet you could actually find something more constructive to do than making comments like this. Owen
On Sun, Feb 06, 2011 at 04:51:26PM -0800, Randy Bush wrote:
it is both amusing and horrifying to watch two old dogs argue about details of written rules as if common sense had died in october 1998. what is good for the internet? what is simple? what is pragmatic? if the answer is not simple and obvious, we should go break something else.
Randy, I'll bite. I'll take "Who cares? Let's keep on' keepin' on..." for $200. Deck chairs indeed. --msa
On Feb 6, 2011, at 2:51 PM, Randy Bush wrote:
it is both amusing and horrifying to watch two old dogs argue about details of written rules as if common sense had died in october 1998.
what is good for the internet? what is simple? what is pragmatic? if the answer is not simple and obvious, we should go break something else.
As would seem apparent, what is simple and obvious to some may be insane and Byzantine to others. Increasingly nteresting times. Regards, -drc
David Conrad <drc@virtualized.org> writes:
I'm curious: when HP acquired the assets of Compaq (or when Compaq acquired the assets of Digital), is it your position that HP (or Compaq) "met the same criteria as if they were requesting an IP address directly from the IR." for 16.0.0.0/8?
since i was the guy to do the initial carving on 16.0.0.0/8 i pondered this at the time of the CPQ and HP acquisitions. my research revealed that the network that DEC had numbered using 16.0.0.0/8 was still in existence and had been part of the acquisition process. there's an interesting question as to whether the acquirer should have had to renumber, since the acquirer had their own /8 and probably had the ability to contain both the old and new networks in the same /8. there's another interesting question as to whether either DEC or HP could have qualified for a /8 under current rules, since the basis for these (pre-RIR) allocations was that they needed more than a /16 and these were the days before CIDR. (at the time i received the /8 allocation at DEC, we had a half dozen /16's several dozen /24's that we wanted to stop using because we worried about the size of the global routing table... what whacky kids we all were. hint: i had hair back then.) -- Paul Vixie KI6YSY
On Wed, Feb 9, 2011 at 10:17 PM, Paul Vixie <vixie@isc.org> wrote:
David Conrad <drc@virtualized.org> writes:
whether either DEC or HP could have qualified for a /8 under current rules, since the basis for these (pre-RIR) allocations was that they needed more than a /16 and these were the days before CIDR. Â (at the time i received the /8 allocation at DEC, we had a half dozen /16's several dozen /24's that
With them not requiring a /8 in the first place (after CIDR); one begins to wonder how much of their /8 allocations they actually touched in any meaningful way. Perhaps the RIRs should personally and directly ask each /8 legacy holder to provide account of their utilization (which portions of the allocation is used, how many hosts), and ASK for each unused /22 [or shorter] to be returned. The legacy holders might (or might not) refuse. They might (or might not) tell the RIRs "Hell no" In any case, the registry should ASK and publish an indication for each legacy /8 at least. So the community will know which (if any) legacy /8 holders are likely to be returning the community's IPv4 addresses that they obtained but don't have need for. The community should also know which /8 legacy holders say "Hell no, we're keeping all our /8s, and not telling you how much of the community's IPv4 resources we're actually using". -- -JH
On Feb 9, 2011, at 11:13 PM, Jimmy Hess wrote:
On Wed, Feb 9, 2011 at 10:17 PM, Paul Vixie <vixie@isc.org> wrote:
David Conrad <drc@virtualized.org> writes:
whether either DEC or HP could have qualified for a /8 under current rules, since the basis for these (pre-RIR) allocations was that they needed more than a /16 and these were the days before CIDR. (at the time i received the /8 allocation at DEC, we had a half dozen /16's several dozen /24's that
With them not requiring a /8 in the first place (after CIDR); one begins to wonder how much of their /8 allocations they actually touched in any meaningful way.
Perhaps the RIRs should personally and directly ask each /8 legacy holder to provide account of their utilization (which portions of the allocation is used, how many hosts), and ASK for each unused /22 [or shorter] to be returned.
The legacy holders might (or might not) refuse. They might (or might not) tell the RIRs "Hell no" In any case, the registry should ASK and publish an indication for each legacy /8 at least.
That depends on whether you want honest answers from the legacy holders or a blanket "We're using the space, move along, these aren't the droids you're looking for." If the RIRs are going to ask, they RIRs should be able to keep the data and provide generalized statistics, or, at least each organization should have the option of opting in to any identifying statistics. Otherwise, you create an incredible motivation for organizations to simply stonewall the RIRs and refuse to tell them anything.
So the community will know which (if any) legacy /8 holders are likely to be returning the community's IPv4 addresses that they obtained but don't have need for.
If they are inclined to return anything, the community will find out what is returned soon enough. There's no real gain to this witch hunt other than feeling like you put pressure on legacy holders to do what you think is the right thing. It may create some small amount of personal satisfaction, but, it won't actually help get addresses freed up. In fact, I think it would be counter-productive.
The community should also know which /8 legacy holders say "Hell no, we're keeping all our /8s, and not telling you how much of the community's IPv4 resources we're actually using".
Yeah, this is a sure path to having all of them say exactly that in unison. Do you want to be right? Or would you prefer to be effective? Owen
On 2/10/2011 1:49 AM, Owen DeLong wrote:
Yeah, this is a sure path to having all of them say exactly that in unison. Do you want to be right? Or would you prefer to be effective?
I think he wants to know which bogons will continue to be safe to use. :P Jack
Date: Thu, 10 Feb 2011 01:13:49 -0600 From: Jimmy Hess <mysidia@gmail.com>
With them not requiring a /8 in the first place (after CIDR); one begins to wonder how much of their /8 allocations they actually touched in any meaningful way.
i expect that after final depletion there will be some paid transfers from some of the large legacy blocks. i have no personal knowledge of HP's situation or indeed any /8 holder's situation, but if the market value of these transfers ever meaningfully exceeds the renumbering penalty then their beancounters will find a way to get it done. that's the way of the world. i can imagine this NOT happening. most businesses are looking for long term strategic investments not quick-fix short-term band-aids. a buddy loaned me a macbook after my thinkpad was stolen, and i loved it, and i went down to the apple store to buy one of my own just like my buddy's loaner and they said "we only sell that with the chicklet keyboard now" and i tried it and hated it. i could buy my buddy's laptop but without applecare and without the ability to replace it if it's lost/stolen i'm not willing to make that investment. so for me it's another thinkpad. so if a company who traditionally needs a lot of IPv4 to grow their network knows that they can get one last quarter's worth of it from some legacy /8 holder, they might do some kind of paid transfer, or they might just hum some dire straits and keep moving with their ipv6 plans. Now it's past last call for alcohol Past recall has been here and gone The landlord finally paid us all The satin jazzmen have put away their horns And we're standing outside of this wonderland Looking so bereaved and so bereft Like a Bowery bum when he finally understands The bottle's empty and there's nothing left (Your Latest Trick) for some IPv4 based businesses a /8 would be more than a lifetime supply, but there's a value ceiling imposed by the space other people can get. (when everybody else has made other arrangements, the relative value of one's own hoard decreases.)
Perhaps the RIRs should personally and directly ask each /8 legacy holder to provide account of their utilization (which portions of the allocation is used, how many hosts), and ASK for each unused /22 [or shorter] to be returned.
The legacy holders might (or might not) refuse. They might (or might not) tell the RIRs "Hell no" In any case, the registry should ASK and publish an indication for each legacy /8 at least.
So the community will know which (if any) legacy /8 holders are likely to be returning the community's IPv4 addresses that they obtained but don't have need for.
The community should also know which /8 legacy holders say "Hell no, we're keeping all our /8s, and not telling you how much of the community's IPv4 resources we're actually using".
this gets into the controversial topic of an RIR's standing with respect to legacy space, and i'll leave that to the lawyers to talk about. but as owen and others have said, if a legacy holder were approached in this way knowing that their answer was going to be on the public record in the way, they probably would see no incentive at all to answer the question.
On Thu, Feb 10, 2011 at 01:13:49AM -0600, Jimmy Hess wrote:
Perhaps the RIRs should personally and directly ask each /8 legacy holder to provide account of their utilization (which portions of the allocation is used, how many hosts), and ASK for each unused /22 [or shorter] to be returned.
And then they (read: their attorneys) fire back a "okay, who are you, and why do you have the right to ask us this question?" Or they cheerfully engage in some vigorous handwaving. Most of us living in a dual stack world really do not need any more prefixes advertised, so cutting a bunch of discrete /22s out of a /8 is not helpful. The only people this benefits are the very few that might get some of the space. Even in the best possible situation (an entire /8 returned,) which they'd be under NO obligation to consider doing -- it'd last a few weeks. Under your scenario, you might scrounge together enough /22s to last an RIR a couple of days. Then what? That's an awful lot of pain for not much benefit. Can we move on and stop trying to squeeze prefixes from legacy holders? What's done is done. --msa
On Feb 10, 2011, at 3:13 AM, Jimmy Hess wrote:
Perhaps the RIRs should personally and directly ask each /8 legacy holder to provide account of their utilization (which portions of the allocation is used, how many hosts), and ASK for each unused /22 [or shorter] to be returned.
I've done close: contacted each one, explained the situation, and asked for whatever resources they can return to please return. This has yielded results. I have not asked for an account of their utilization.
The legacy holders might (or might not) refuse. They might (or might not) tell the RIRs "Hell no" In any case, the registry should ASK and publish an indication for each legacy /8 at least.
I asked them all. Some have been returned, some are in progress, some are opted to hold them to be monetized via the Specified Transfer policy.
So the community will know which (if any) legacy /8 holders are likely to be returning the community's IPv4 addresses that they obtained but don't have need for.
There is likely to be another fractional /8 being returned, but not much more.
The community should also know which /8 legacy holders say "Hell no, we're keeping all our /8s, and not telling you how much of the community's IPv4 resources we're actually using".
As I did not explain in advance to each to the parties that their responses would be public, it would not be proper to publicly post the information. Discussions with individual resource holders is treated as confidential information. FYI, /John John Curran President and CEO ARIN
On 2/10/2011 6:07 PM, John Curran wrote:
As I did not explain in advance to each to the parties that their responses would be public, it would not be proper to publicly post the information. Discussions with individual resource holders is treated as confidential information.
Since you have gone through the process before. It would be nice (especially concerning the DoD networks) if you could ask if they plan to keep them (not monetize) and if you could make such a statement publicly. I mention this, as DoD is most common bogons utilized by people who need to steal IP addressing. Locking in a statement that there is no intention to ever sell, transfer, or return those blocks would ease possible concerns on using them. As a side effect, it also kills any need of any proposals in various institutions to reserve virgin space for utilization of LSN and such. Jack
On 2/10/2011 8:10 PM, Jack Bates wrote:
As a side effect, it also kills any need of any proposals in various institutions to reserve virgin space for utilization of LSN and such.
It might not be too far fetched that they might even endorse us reusing their addressing with permission for such private, non-routed purposes. Jack
On Feb 10, 2011, at 10:10 PM, Jack Bates wrote:
Since you have gone through the process before. It would be nice (especially concerning the DoD networks) if you could ask if they plan to keep them (not monetize) and if you could make such a statement publicly.
I mention this, as DoD is most common bogons utilized by people who need to steal IP addressing. Locking in a statement that there is no intention to ever sell, transfer, or return those blocks would ease possible concerns on using them.
I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy. /John John Curran President and CEO ARIN
On 2/10/2011 8:15 PM, John Curran wrote:
I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy.
An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :) Jack
On Feb 10, 2011, at 10:31 PM, Jack Bates wrote:
On 2/10/2011 8:15 PM, John Curran wrote:
I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy.
An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :)
In organizations of all sizes, positions and policies change, with revised statements as a result. One thing that does not change, however, is contractual commitments, and in this one case I can state that there is a commitment to return IPv4 address blocks to ARIN for reuse by the community if they no longer needed. If you'd like to reserve a large block for purposes of LSN without any concern of future address conflict, it would be best to actually reserve it via community-developed policy. FYI, /John John Curran President and CEO ARIN
On 2/10/2011 8:44 PM, John Curran wrote:
If you'd like to reserve a large block for purposes of LSN without any concern of future address conflict, it would be best to actually reserve it via community-developed policy.
When there are X /8 networks reserved by the USG, it seems extremely wasteful to reserve from what little space we have a large block dedicated to LSN when the USG can give assurances that 1) We won't route this, so use it 2) We won't be giving it back or allocating it to someone else where it might be routed. All proposals concerning reserving a /8 of unallocated space for LSN purposes was seen as obscene, and many proposals compromised with a /10, which some feel is too small. I don't think it would hurt for someone with appropriate connections to ask the USG on the matter. It is, after all, in the USG's interest and doesn't conflict with their current practices. Many don't consider it a concern (shown by wide use of DoD space already deployed), yet some do apparently have concern since there has been multiple requests for a new allocation for LSN purposes (in the IETF and in RIRs). Jack
On Feb 10, 2011, at 9:54 PM, Jack Bates wrote:
On 2/10/2011 8:44 PM, John Curran wrote:
If you'd like to reserve a large block for purposes of LSN without any concern of future address conflict, it would be best to actually reserve it via community-developed policy.
When there are X /8 networks reserved by the USG, it seems extremely wasteful to reserve from what little space we have a large block dedicated to LSN when the USG can give assurances that
1) We won't route this, so use it
2) We won't be giving it back or allocating it to someone else where it might be routed.
All proposals concerning reserving a /8 of unallocated space for LSN purposes was seen as obscene, and many proposals compromised with a /10, which some feel is too small. I don't think it would hurt for someone with appropriate connections to ask the USG on the matter. It is, after all, in the USG's interest and doesn't conflict with their current practices. Many don't consider it a concern (shown by wide use of DoD space already deployed), yet some do apparently have concern since there has been multiple requests for a new allocation for LSN purposes (in the IETF and in RIRs).
Jack, I was explaining to my wife today how it felt like the nanog list went to 3x the typical mail volume recently with all the IPv6 stuff this month. Why the pro-IPv6 crowd was happy, the anti-IPv6 crowd is groaning (including those that truly despise the whole thing, etc..) I honestly think that the LSN situations won't be as bad as some of us think. The big carriers have already been doing some flavor of this with their cellular/data networks. Doing this on some of the consumer networks will likely not be "that much" pain. Obviously the pain will vary per subscriber/home. I think despite everyones dislike, distaste and wish that the IPv6 situation didn't smell quite as bad as it does, we're certainly stuck with it. I don't see anyone deploying a new solution anytime soon, and it having broad market acceptance/coding. Many of us wish that IPv6 didn't have a lot of "unecessary/ugly" stuff. I wish that the network situation wasn't as ugly, but none of this will make it so. We will have to continue to improve and augment the autoconf, dhcpv6, etc environment. The existing hosts need to be fixed (eg: my laptop won't do ipv6 over pptp/vpn properly without a hack), etc.. IPv4 is "dead" in my opinion. Not dead as in useless, but to the point where I don't think there is value in spending a lot of time worrying about the v4 side of the world when so much needs to be fixed in IPv6 land. Please make sure you list IPv6 *first* in your RFPs, and the IPv4 capabilities under the 'legacy protocols' for 2011. If we're truly going to have the promise of the Internet, we need these market forces to drive the carriers and SME/Prosumer markets to lead the way for the grandparents to still get to their "Google, Bing" et al, and not just those of us who know there will be an IPv6 day and have our mailboxes filled with IPv6 "spam" this month. - Jared
On 2/10/2011 9:11 PM, Jared Mauch wrote:
I was explaining to my wife today how it felt like the nanog list went to 3x the typical mail volume recently with all the IPv6 stuff this month. Why the pro-IPv6 crowd was happy, the anti-IPv6 crowd is groaning (including those that truly despise the whole thing, etc..)
I was having fun discussing with my wife how ARIN stuff ended up on NANOG, NANOG stuff ended up on PPML, and I've been listening and participating in debates concerning IPv6 and CGN (apparently BEHAVE WG adopted CGN over LSN) on 4 different mailing lists. To be honest, though. I'm pro-IPv6, but I'm not happy. Anyone who is happy doesn't care about those innocent people who are ignorant of what is going on and why.
I honestly think that the LSN situations won't be as bad as some of us think. The big carriers have already been doing some flavor of this with their cellular/data networks. Doing this on some of the consumer networks will likely not be "that much" pain. Obviously the pain will vary per subscriber/home.
IPv4 is "dead" in my opinion. Not dead as in useless, but to the point where I don't think there is value in spending a lot of time worrying about the v4 side of the world when so much needs to be fixed in IPv6 land. Service requirements in cellular networks are considerably different
<snip lots of good stuff I agree with> than wireline. Apparently, most cell customers don't hook a CPE router into their cell network and play their game consoles over it, along with many other situations. This actually means that most often, they are running a single stage NAT44 LSN (which still breaks stuff, but most of the things it would break aren't normally transiting the cellular networks). <snip more good stuff I agree with> I agree. However, because the largest networks and corporations decided (and some still do) to wait until the last moment to deal with IPv6, we will have to deal with IPv4 in much worse conditions. I know that there are large cellular networks which use DoD bogons behind huge LSN implementations. I know that some networks apparently aren't happy with using DoD bogons and would like to waste even more space. The best solution for such a case (and to solve all arguments on the matter) is to secure assurances on the bogons so that they can be safely used. Jack
There are major GSM-land wireless operators who provide service to devices like Novatel's line of pocket-size WLAN hotspots. You can just buy one and stick a SIM in it, but some of the ops offer them as part of a business user package. I hope that means they get a proper IP or more handed out from the SGSN, as otherwise this would be a true orgy of NAT. (Top posting on mobile) "Jack Bates" <jbates@brightok.net> wrote:
I was explaining to my wife today how it felt like the nanog list went to 3x the typical mail volume recently with all the IPv6 stuff
On 2/10/2011 9:11 PM, Jared Mauch wrote: this month. Why the pro-IPv6 crowd was happy, the anti-IPv6 crowd is groaning (including those that truly despise the whole thing, etc..)
I was having fun discussing with my wife how ARIN stuff ended up on NANOG, NANOG stuff ended up on PPML, and I've been listening and participating in debates concerning IPv6 and CGN (apparently BEHAVE WG adopted CGN over LSN) on 4 different mailing lists.
To be honest, though. I'm pro-IPv6, but I'm not happy. Anyone who is happy doesn't care about those innocent people who are ignorant of what
is going on and why.
I honestly think that the LSN situations won't be as bad as some of us think. The big carriers have already been doing some flavor of this with their cellular/data networks. Doing this on some of the consumer networks will likely not be "that much" pain. Obviously the pain will vary per subscriber/home.
IPv4 is "dead" in my opinion. Not dead as in useless, but to the
<snip lots of good stuff I agree with> point where I don't think there is value in spending a lot of time worrying about the v4 side of the world when so much needs to be fixed in IPv6 land. Service requirements in cellular networks are considerably different than wireline. Apparently, most cell customers don't hook a CPE router into their cell network and play their game consoles over it, along with many other situations. This actually means that most often, they are running a single stage NAT44 LSN (which still breaks stuff, but most of
the things it would break aren't normally transiting the cellular networks).
<snip more good stuff I agree with>
I agree. However, because the largest networks and corporations decided
(and some still do) to wait until the last moment to deal with IPv6, we
will have to deal with IPv4 in much worse conditions. I know that there
are large cellular networks which use DoD bogons behind huge LSN implementations. I know that some networks apparently aren't happy with
using DoD bogons and would like to waste even more space. The best solution for such a case (and to solve all arguments on the matter) is to secure assurances on the bogons so that they can be safely used.
Jack
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Feb 10, 2011, at 10:54 PM, Jack Bates wrote:
When there are X /8 networks reserved by the USG, it seems extremely wasteful to reserve from what little space we have a large block dedicated to LSN when the USG can give assurances that
1) We won't route this, so use it
2) We won't be giving it back or allocating it to someone else where it might be routed.
All proposals concerning reserving a /8 of unallocated space for LSN purposes was seen as obscene, and many proposals compromised with a /10, which some feel is too small. I don't think it would hurt for someone with appropriate connections to ask the USG on the matter. It is, after all, in the USG's interest and doesn't conflict with their current practices. Many don't consider it a concern (shown by wide use of DoD space already deployed), yet some do apparently have concern since there has been multiple requests for a new allocation for LSN purposes (in the IETF and in RIRs).
Indeed, that does sound simple. Obtaining such a commitment may prove to be a little more difficult, since it permanently encumbers use of one or more address blocks. I am happy to ask, however, if there is a strong level of support to do so. Alternatively, there is valid contact information listed in WHOIS for US DOD and other commercial /8 address block holders if you wish to ask one directly. /John John Curran President and CEO ARIN p.s. Considering that we've collectively allocated the 95%+ of the address space which was made available outside of DoD's original blocks, and the DoD additionally returned 2 more /8's for the community (noted here: <http://blog.icann.org/2008/02/recovering-ipv4-address-space/>), they may actually have a different perspective us coming back to impair some of the remaining space they still hold. I'm happy to discuss it, but wanted to point out the long history and potential different perspective.
On 2/10/11 6:54 PM, Jack Bates wrote:
On 2/10/2011 8:44 PM, John Curran wrote:
If you'd like to reserve a large block for purposes of LSN without any concern of future address conflict, it would be best to actually reserve it via community-developed policy.
When there are X /8 networks reserved by the USG, it seems extremely wasteful to reserve from what little space we have a large block dedicated to LSN when the USG can give assurances that
reserved and assigned are different. The prefixes are assigned.
1) We won't route this, so use it
2) We won't be giving it back or allocating it to someone else where it might be routed.
All proposals concerning reserving a /8 of unallocated space for LSN purposes was seen as obscene, and many proposals compromised with a /10, which some feel is too small. I don't think it would hurt for someone with appropriate connections to ask the USG on the matter. It is, after all, in the USG's interest and doesn't conflict with their current practices. Many don't consider it a concern (shown by wide use of DoD space already deployed), yet some do apparently have concern since there has been multiple requests for a new allocation for LSN purposes (in the IETF and in RIRs).
Jack
On Feb 10, 2011, at 9:44 PM, John Curran wrote:
On Feb 10, 2011, at 10:31 PM, Jack Bates wrote:
On 2/10/2011 8:15 PM, John Curran wrote:
I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy.
An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :)
In organizations of all sizes, positions and policies change, with revised statements as a result. One thing that does not change, however, is contractual commitments, and in this one case I can state that there is a commitment to return IPv4 address blocks to ARIN for reuse by the community if they no longer needed.
If you'd like to reserve a large block for purposes of LSN without any concern of future address conflict, it would be best to actually reserve it via community-developed policy.
I would have to say I agree. Anything short of a posting in the federal register is just a statement of the short-term future. US Gov 201: The federal register from the GPO is the primary source of rule making and RFI the government will use prior to regulation that is not purely legislative. It may be worthwhile to subscribe, or periodically read/search. - Jared
In message <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net>, John Curran writes:
On Feb 10, 2011, at 10:31 PM, Jack Bates wrote:
On 2/10/2011 8:15 PM, John Curran wrote:
I'm not certain that you could rely on any organizations statements made= today to provide any assurance that circumstances would not change in the futu= re and result in the address space being returned to ARIN or transferred per cu= rrent policy. =20 An official statement from the DoD? I'm sure we could hold them to it as = a community. Is it too much for us to ask the US government to give us assu= rance that we can safely utilize huge chunks of address space assigned to t= hem for purposes such as LSN without fear? :)
In organizations of all sizes, positions and policies change,=20 with revised statements as a result. One thing that does not change, however, is contractual commitments, and in this one case I can state that there is a commitment to return IPv4=20 address blocks to ARIN for reuse by the community if they no=20 longer needed.
If you'd like to reserve a large block for purposes of LSN=20 without any concern of future address conflict, it would be=20 best to actually reserve it via community-developed policy.
The first half of Class E would work. There are 134+ million addresses there and you only have to be able to route it between the CPE and the LSN / 6rd BR. The CPE signals that it support Class E (DHCP/PPP option) and the ISP only assigns a address from the block if it knows the path is Class E clean. Anyone that can't work with double NAT would clear the option and it would be on by default. It should be possible to patch all existing CPE devices to support this without flash memory constraints. The same can't be said for upgrading then to support IPv6. It does require the whole world to upgrade to be useful. It can be done incrementally. It will significiantly reduce the remaining IPv4 consumption rate. Those CPE's that turn on 6to4 automatically now have another well known address range where it is known not to work. It doesn't clash with address ranges already in use by customers. It can be used with 6rd so that IPv6 can be deployed over it for ISP's that have boxes that can't be upgraded to IPv6. It gives them a little more breathing room.
FYI, /John
John Curran President and CEO ARIN -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Thu Feb 10 20:35:01 2011 Date: Thu, 10 Feb 2011 20:31:32 -0600 From: Jack Bates <jbates@brightok.net> To: John Curran <jcurran@arin.net> Subject: Re: "Leasing" of space via non-connectivity providers Cc: NANOG <nanog@merit.edu>
On 2/10/2011 8:15 PM, John Curran wrote:
I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy.
An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :)
Even the DoD cannot say "for sure" that they would never route some of that space 'in time of need' over the public internet.
participants (13)
-
Alexander Harrowell -
David Conrad -
Jack Bates -
Jared Mauch -
Jimmy Hess -
Joel Jaeggli -
John Curran -
Majdi S. Abbas -
Mark Andrews -
Owen DeLong -
Paul Vixie -
Randy Bush -
Robert Bonomi