De-bogon not possible via arin policy.
Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I own ~100k ipv4 addresses today. My customers use over 10 million bogon / squat space ip addresses today, and I have good attested data on that. But all I can qualify for is a /18, and then in 3 months maybe a /17. This is called slow start ? For an established business? Just fyi, de-bogoning , or private rfc 1918 is not really an option even with strong and consistent demonstrate load. Any suggestions on how to navigate this policy ?
Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I own ~100k ipv4 addresses today.> My customers use over 10 million bogon / squat space ip addresses today, and I have good attested data on that. But all I can qualify for is a /18, and then in 3 months maybe a /17. This is called slow start ? For an established business? Just fyi, de-bogoning , or private rfc 1918 is not really an option even with strong and consistent demonstrate load.
Any suggestions on how to navigate this policy ?
You should easily qualify for a /32 or larger IPv6 block. And it's curious that errors that are likely to be there for decades are just now trying to be fixed as IPv4 pool is depleted, isn't it ? Rubens
On 12/14/2011 4:20 PM, Rubens Kuhl wrote:
You should easily qualify for a /32 or larger IPv6 block. And it's curious that errors that are likely to be there for decades are just now trying to be fixed as IPv4 pool is depleted, isn't it ?
His users can also switch to DECNET and reach about as many internet sites as they would with IPv6. Ooh well, internet's dieing, lets pack up our routers and go home. Randy Bush will turn out the lights for us. Andrew
What do you mean by "de-bogon"? Do you mean that your customers' addresses are listed in various RBLs for previous misbehavior? That they are using addresses that were never properly allocated to them? Something different? You don't "own" IPv4 addresses; they are assigned or allocated to you in response to demonstrated need. ARIN takes into account your history of needing IP address space when evaluating your request for more address space to be assigned or allocated to you. If you have not been back to ARIN for address space recently (or ever, if these are legacy addresses), you may find yourself subject to slow start just like a newly established entity. It does not sound as if ARIN rejected you for an IPv4 allocation.
From your statement below, it sounds as if ARIN approved you for a /18, which is reasonable and in accordance with current policies. If you walked in to ARIN and asked them for 10 million IPv4 addresses (which is on the order of 1/8 of the total that ARIN has on hand, for everyone), it is unsurprising that they declined.
If you can clarify the problem, it's possible the community may be able to offer assistance. -r PS: I'm on the ARIN Advisory Council, which means that I help with policy creation. Neither I nor my 14 colleagues on the AC are employees; staff won't discuss particular cases, etc. So if you want us to know something, you'll have to state it here or in private email or something. Cameron Byrne <cb.list6@gmail.com> writes:
Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I own ~100k ipv4 addresses today.
My customers use over 10 million bogon / squat space ip addresses today, and I have good attested data on that.
But all I can qualify for is a /18, and then in 3 months maybe a /17. This is called slow start ? For an established business?
Just fyi, de-bogoning , or private rfc 1918 is not really an option even with strong and consistent demonstrate load.
Any suggestions on how to navigate this policy ?
On Dec 14, 2011, at 1:15 PM, Cameron Byrne wrote:
Just fyi, de-bogoning , or private rfc 1918 is not really an option even with strong and consistent demonstrate load.
Any suggestions on how to navigate this policy ?
Given unmet demand, I'd think the solution would be fairly obvious (albeit likely quite expensive with the going rate being around $12/address). I'd guess some of the folks who would be more than happy to help you (in exchange for a transaction fee of course) will contact you in the near future (if they haven't already). Regards, -drc
On Wed, Dec 14, 2011 at 4:15 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I own ~100k ipv4 addresses today.
My customers use over 10 million bogon / squat space ip addresses today, and I have good attested data on that.
Cameron, I have a client who went through the same problem in early-2011. They had several thousand residential and small business end-users behind NAT and wished to provision public IP addresses for them. They assumed ARIN would be pleased to issue an appropriate block for their project. David Huberman rejected their request outright and told them to request provider space, renumber the customers to provider IPs, and then apply to ARIN again and renumber their network a second time. The client did not bother to involve me until after they had already been told to FOAD. This is clearly a counter-productive waste of time, but if the client had applied using the immediate need process, and provided the additional supporting documentation required by that, I think they would not have had this problem. The analyst you worked with should have suggested a different application procedure or otherwise worked with you to facilitate your request. Sometimes the ARIN staff are nice and helpful, sometimes they are not. It depends on who you get assigned to, price of tea in china, phase of the moon, etc. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Wed, Dec 14, 2011 at 3:15 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I own ~100k ipv4 addresses today. My customers use over 10 million bogon / squat space ip addresses today, and I have good attested data on that.
Wait... you had started using bogon addresses / "squatted" space not allocated and claimed the number of IP addresses your network is using that were not allocated by a RIR settles the need justification question?
Any suggestions on how to navigate this policy ?
Work with ARIN to provide a satisfactory need justification for the entire allocation you are requesting. A mere count of the number of IP addresses you are currently using is not a need justification. There has to be a technical reason that each IP address is required. "I'm making IANA-unsanctioned use of 10^9 bogon IP addresses, please allocate me 10^9 proper IP addresses, so I can have matching allocated IP space with global recognition instead"; just doesn't cut it. You need to have all the documentation to show the actual justified technical need for the IPs you request, such as what each specific address is used for. Regards, -- -JH
On 12/14/11 18:46 , Jimmy Hess wrote:
On Wed, Dec 14, 2011 at 3:15 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I own ~100k ipv4 addresses today. My customers use over 10 million bogon / squat space ip addresses today, and I have good attested data on that.
Wait... you had started using bogon addresses / "squatted" space not allocated and claimed the number of IP addresses your network is using that were not allocated by a RIR settles the need justification question?
Anyone who has used their network in the last decade that actually bother to look at their assigned ip address knows this.
Any suggestions on how to navigate this policy ?
Work with ARIN to provide a satisfactory need justification for the entire allocation you are requesting. A mere count of the number of IP addresses you are currently using is not a need justification.
The wikipedia page shows something on the order of 34 million customers. I don't expect they all need an ip at the same time.
There has to be a technical reason that each IP address is required.
"I'm making IANA-unsanctioned use of 10^9 bogon IP addresses, please allocate me 10^9 proper IP addresses, so I can have matching allocated IP space with global recognition instead"; just doesn't cut it.
You need to have all the documentation to show the actual justified technical need for the IPs you request, such as what each specific address is used for.
Regards, -- -JH
On Dec 14, 2011, at 6:46 PM, Jimmy Hess wrote
Wait... you had started using bogon addresses / "squatted" space not allocated and claimed the number of IP addresses your network is using that were not allocated by a RIR settles the need justification question?
I'm confused. When justifying 'need' in an address allocation request, what difference does it make whether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumbering out of (say) RFC 1918 space into public space was still a justification for address space. Has this changed?
You need to have all the documentation to show the actual justified technical need for the IPs you request, such as what each specific address is used for.
Perhaps I'm naive, but I tend to give folks like Cameron the benefit of the doubt when it comes to dealing with IP address allocation requests and assume he provided a bit more information than what you're suggesting. I find the suggestions by other posters that he look at IPv6 particularly amusing. Unfortunately, regardless of the specifics of Cameron's case, the reality is that the traditional model of address allocation (i.e., "to each according to need" to quote a 19th century philosopher) is rapidly coming to a close. I expect there will be many more situations like Cameron's in the future. Regards, -drc
On Wed, Dec 14, 2011 at 10:47 PM, David Conrad <drc@virtualized.org> wrote: [snip]
I'm confused. When justifying 'need' in an address allocation request, what difference does it make >whether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumbering >out of (say) RFC 1918 space into public space was still a justification for address space. Has this >changed?
It is a potential network change that could require additional address space, if an operator plans a complete and immediate renumbering, but the choice to renumber is not an automatic justification for the same number of non-RFC1918 IPs as the count of IPs available in their RFC1918 space networks. I'm sure the RIRs are not allowing that. A RFC1918 network is not a "normal" network; and this is not a renumbering in the same manner as a renumbering from public IP space to new public IP space. The operator might have to show why they shouldn't renumber their 1918 network partially, over time, in a manner compatible with the RIR policy for initial service provider allocations, instead of all at once. In other words: What is the technical justification that all those rfc1918 addressed hosts suddenly need to be moved immediately, and not over a normal allocation time frame for new public networks? When building the rfc1918 network originally, the architect did not need to follow RFC 2050, RFC3194, etc, so it is quite possible that the 1918 network does not efficiently utilize IP addresses. That means the RIR has to establish that the criterion is good enough. "I have a rfc1918 /16 that I use, so give me a public /16, please" is not good enough. That would essentially provide a backdoor around normal RIR justified need policy, if it were allowed...... -- -JH
I'm also aware of at least one network that has consumed all private address space, perhaps even including the testing /15 as well. If you are using a /8 /12 and /16 in total, ones future life could be very interesting. Almost makes the case for v6 easier at their site. I'm hoping we see 2012 as the date of broadband v6 becoming commonly available in the states at least. Jared Mauch On Dec 15, 2011, at 8:14, Jimmy Hess <mysidia@gmail.com> wrote:
That would essentially provide a backdoor around normal RIR justified need policy, if it were allowed......
On 12/14/2011 11:14 PM, Jimmy Hess wrote:
I'm confused. When justifying 'need' in an address allocation request, what difference does it make>whether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumbering>out of (say) RFC 1918 space into public space was still a justification for address space. Has this>changed? It is a potential network change that could require additional address space, if an operator plans a complete and immediate renumbering, but
On Wed, Dec 14, 2011 at 10:47 PM, David Conrad<drc@virtualized.org> wrote: [snip] the choice to renumber is not an automatic justification for the same number of non-RFC1918 IPs as the count of IPs available in their RFC1918 space networks. I'm sure the RIRs are not allowing that.
A RFC1918 network is not a "normal" network; and this is not a renumbering in the same manner as a renumbering from public IP space to new public IP space.
The operator might have to show why they shouldn't renumber their 1918 network partially, over time, in a manner compatible with the RIR policy for initial service provider allocations, instead of all at once.
In other words: What is the technical justification that all those rfc1918 addressed hosts suddenly need to be moved immediately, and not over a normal allocation time frame for new public networks?
Here's a simple one involving "squat" space: You have a network that internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you have enough customers to fill two /8s). Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites). Why wouldn't this be sufficient justification for a new /8 from ARIN? Matthew Kaufman
On Thu, 15 Dec 2011 07:42:40 PST, Matthew Kaufman said:
Here's a simple one involving "squat" space: You have a network that internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you have enough customers to fill two /8s).
Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites).
Why wouldn't this be sufficient justification for a new /8 from ARIN?
Because you can probably use the other two 10/8's you already have. And if thiose run out, a third 10/8 is cheap even on the secondary market.
On 12/15/2011 8:05 AM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 15 Dec 2011 07:42:40 PST, Matthew Kaufman said:
Here's a simple one involving "squat" space: You have a network that internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you have enough customers to fill two /8s).
Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites).
Why wouldn't this be sufficient justification for a new /8 from ARIN? Because you can probably use the other two 10/8's you already have. And if thiose run out, a third 10/8 is cheap even on the secondary market.
You're assuming a network architecture which is not required by policy. Matthew Kaufman
On Thu, Dec 15, 2011 at 10:53 AM, Matthew Kaufman <matthew@matthew.at> wrote:
On 12/15/2011 8:05 AM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 15 Dec 2011 07:42:40 PST, Matthew Kaufman said:
Here's a simple one involving "squat" space: You have a network that internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you have enough customers to fill two /8s). Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites). Why wouldn't this be sufficient justification for a new /8 from ARIN?
It is valid justification you may have available to obtain some additional address space from ARIN. Probably not a /8, however. With such a large request, you can be sure the RIR will want to vet it in great detail, and make sure everything is fully justified technically, to the letter and spirit of the policy. If it is, then you get a /8, providing it is available, and the policy is still justified need. If you don't immediately require an entire /8 equivalent, you can expect to get a smaller amount immediately. You are only allowed a 3 months supply, anyways, and you may not get to have the /8 as a single aggregate. The limitation is that "Efficiently utilizing 10.0.0.0/8" or "Efficiently utilizing 5.0.0.0/8" Cannot be used to obtain a /7 or another /8, because 10.0.0.0/8 and 5.0.0.0/8 are not your allocation. If the allocation is not yours, then you cannot apply the policy that says "Efficient utilization of previous blocks assigned and requirement for more addresses" as the justification for more IPs, because 10/8 wasn't assigned to you anyways. You are left having to justify based on number of simultaneous HOSTS on your network, not number of customers. The RIRs do not currently require you to utilize NAT or RFC1918 addresses for hosts on your network, so if you met the requirements, you can justify the allocations required to renumber your entire 10/8 and your entire 5/8 into public IP space, at the rate you intend to renumber them. You however don't get to say "I have 10 million DSL customers", therefore, I get 10 million IPs, right now.
Because you can probably use the other two 10/8's you already have. And if thiose run out, a third 10/8 is cheap even on the secondary market. You're assuming a network architecture which is not required by policy. Matthew Kaufman
The RIRs do not require you to utilize NAT in the first place. It follows that they also don't require you to segment your network and re-use the same NAT ranges. But in utilizing NAT, you might be utilizing your address space inefficiently, because the pressure to utilize addresses efficiently is reduced by the large size of 1918 space. An example would be having 10 million dialup customers, with hosts that are only transiently connected to a network, and never 10 million simultaneously, each you addressed with a permanent IP. The problem with that, is you only get to assign addresses to addressable objects. When a device is not connected to your network, it is not an addressable object. In obtaining an allocation from an RIR, you can expect to be required to utilize your address space efficiently, which means that devices not connected to your network at any point in time are not hosts, and therefore do not have IP addresses assigned from you. And the number of IP addresses you can justify is related to the number of simultaneous connected devices. -- -JH
On Thu, 15 Dec 2011 10:42:40 -0500, Matthew Kaufman <matthew@matthew.at> wrote:
Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites).
Why wouldn't this be sufficient justification for a new /8 from ARIN?
Because it's not ARIN's job to clean up someone else's stupid. You chose to use address space that would eventually be allocated, thus creating a (future) mess for yourself; now you're left to live with it. (For the record, there's no easy way out of that mess now.)
On Dec 15, 2011, at 12:41 PM, Ricky Beam wrote:
Because it's not ARIN's job to clean up someone else's stupid.
ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. As I've said, I haven't been following ARIN's policy discussions -- can you point me to the policy that says allocations can be denied because you happened to have (demonstrably ill-advisedly) used the wrong bit patterns in setting up your network? Thanks, -drc
In a message written on Thu, Dec 15, 2011 at 01:36:32PM -0800, David Conrad wrote:
ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. As I've said, I haven't been following ARIN's policy discussions -- can you point me to the policy that says allocations can be denied because you happened to have (demonstrably ill-advisedly) used the wrong bit patterns in setting up your network?
The problem is that "in use" means different things to differnet folks. ifconfig em0 inet 10.0.0.1 255.0.0.0 I'm now using 16 million IP addresses at home. ARIN policy does not allow me to get 16 million public IP addresses as a result, based on the 1 machine I have configured at the moment. In the case at hand we don't know if the original poster configured up /16's on p2p links for two hosts each, or if they have an actual host up and pingable at every single IP address. ARIN has a duty to the community to ask these questions, because otherwise anyone could fabricate a "need" for as many addresses as they want. It would seem the original poster and ARIN have a disagrement in this case as to how many IP addresses are required to support their needs. Perhaps incomplete information was provided, perhaps ARIN staff got it wrong. No one on NANOG has enough information to know either way. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 12/15/11 13:43 , Leo Bicknell wrote:
In a message written on Thu, Dec 15, 2011 at 01:36:32PM -0800, David Conrad wrote:
ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. As I've said, I haven't been following ARIN's policy discussions -- can you point me to the policy that says allocations can be denied because you happened to have (demonstrably ill-advisedly) used the wrong bit patterns in setting up your network?
The problem is that "in use" means different things to differnet folks.
ifconfig em0 inet 10.0.0.1 255.0.0.0
I'm now using 16 million IP addresses at home. ARIN policy does not allow me to get 16 million public IP addresses as a result, based on the 1 machine I have configured at the moment.
In the case at hand we don't know if the original poster configured up /16's on p2p links for two hosts each, or if they have an actual host up and pingable at every single IP address. ARIN has a duty to the
We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. I think it's safe to assume that adequate docuementation could be provided.
community to ask these questions, because otherwise anyone could fabricate a "need" for as many addresses as they want.
It would seem the original poster and ARIN have a disagrement in this case as to how many IP addresses are required to support their needs. Perhaps incomplete information was provided, perhaps ARIN staff got it wrong. No one on NANOG has enough information to know either way.
On Thu, Dec 15, 2011 at 4:54 PM, Joel jaeggli <joelja@bogus.com> wrote:
We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. I think it's safe to assume that adequate docuementation could be provided.
I missed the post where he supplied this information. I guess his company should have cheated the system, with full complicity of ARIN, like Verizon Wireless did a few years ago. http://marc.info/?l=nanog&m=123406577704970&w=4 -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On 12/15/11 14:12 , Jeff Wheeler wrote:
On Thu, Dec 15, 2011 at 4:54 PM, Joel jaeggli <joelja@bogus.com> wrote:
We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. I think it's safe to assume that adequate docuementation could be provided.
I missed the post where he supplied this information.
I imagine the NANOG community to be small enough that the regular participants should be known to each other. Possibly naive, I know.
I guess his company should have cheated the system, with full complicity of ARIN, like Verizon Wireless did a few years ago. http://marc.info/?l=nanog&m=123406577704970&w=4
I figured the discussion was for illustrative purposes more than anything.
On 15-Dec-11 15:54, Joel jaeggli wrote:
On 12/15/11 13:43 , Leo Bicknell wrote:
In a message written on Thu, Dec 15, 2011 at 01:36:32PM -0800, David Conrad wrote:
ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. The problem is that "in use" means different things to differnet folks.
ifconfig em0 inet 10.0.0.1 255.0.0.0
I'm now using 16 million IP addresses at home. ARIN policy does not allow me to get 16 million public IP addresses as a result, based on the 1 machine I have configured at the moment. We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america.
For those that haven't bothered to look it up, folks appear to be referring to T-Mobile--a Cameron Byrne works there, and they fit the profile given.
I think it's safe to assume that adequate docuementation could be provided.
One might assume it /could/ be provided, but so far we have no evidence that it /has/ been provided or, if so, on what grounds ARIN rejected it as being adequate. Heck, so far we have no evidence that any request has even been filed or that the OP is who we think he is. All we have so far is the word of one person, using a Gmail address and the name of a T-Mobile employee, that such addresses were applied for and that ARIN denied the request. I'll also point out that, even if some of the above claims turn out to be true, T-Mobile almost certainly would have required ARIN to sign an NDA (as is customary for any almost any business dealings these days), so ARIN cannot defend itself against the ones that are not, leaving us only with the OP's obviously biased version of events and the ensuing speculation--and the OP probably knew that when he/she posted. Furthermore, it is a fact that not all of T-Mobile's ~34M customers are using IPv4-addressable devices, and they're certainly not all online at the same time, so a simple customer count does /not/ qualify as justification for getting that many addresses. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
In a message written on Thu, Dec 15, 2011 at 01:54:28PM -0800, Joel jaeggli wrote:
We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. I think it's safe to assume that adequate docuementation could be provided.
As I suspect there are a few confused people here, the OP did not post that information. Google shows Cameron Byrne works at T-Moble USA, per his LinkedIn, and I believe Joel is citing that T-Moble has ~34 Million subscribers, which seems to match some recent info. It appears to me folks are _assuming_ his request to ARIN was for T-Moble, and covered all 34 Million users. Of course that still doesn't mean 34 million IP addresses are required. T-Moble sells phones today that can't do anything IP related (http://www.t-mobile.com/shop/Phones/cell-phone-detail.aspx?cell-phone=Samsun..., as an example), and even for the phones that can do IP not all of them are connected at once. I will repeat myself though, we don't know what was submitted to ARIN, or why they responded the way they did. Having the OP come whine to NANOG without us having that information is useless. ARIN's PPML list might be more helpful, or some AC members. Heck, even picking up the phone and talking to ARIN might work better. To bring this back on topic for NANOG though, they need to get it sorted quickly. ARIN shows an equivilent of 5.63 /8's in inventory right now. If 34 million addresses are needed, and can be used to 80% effiency that would require ~2.5 /8's worth of space. It would only take a couple of these sorts of requests and the free pool is gone. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad <drc@virtualized.org> wrote:
... I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed.
That depends on how you see their "demontrated need." The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any "immediate need" on my (channeling ARIN) part. This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.) And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.)
On 15-Dec-11 16:31, Ricky Beam wrote:
On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad <drc@virtualized.org> wrote:
... I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed.
That depends on how you see their "demontrated need." The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any "immediate need" on my (channeling ARIN) part.
However, if they actually have the number of hosts claimed, that justifies the space they're asking for. What addresses they're using today is irrelevant. ARIN policy only /suggests/ that they use RFC 1918 space; they are allowed to get public space if they want it.
This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.)
Agreed, but what's done is done. What /should/ have been done is now irrelevant.
And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.)
Presumably, they "need" to renumber out of 5/8 so that their customers can reach sites legitimately assigned addresses in 5/8. However, those customers seem to have gotten along okay for years without public addresses, so why not renumber them into a second instance of 10/8? When I was in the consulting world, I had one customer with eight instances of 10/8, so I know it's doable. If they want to give every customer a public address, IPv6 provides more than they could ever possibly use--and ~34M new IPv6 eyeballs would give the content industry a nice kick in the pants... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Dec 15, 2011 6:43 PM, "Stephen Sprunk" <stephen@sprunk.org> wrote:
On 15-Dec-11 16:31, Ricky Beam wrote:
On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad <drc@virtualized.org> wrote:
... I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed.
That depends on how you see their "demontrated need." The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any "immediate need" on my (channeling ARIN) part.
However, if they actually have the number of hosts claimed, that justifies the space they're asking for. What addresses they're using today is irrelevant. ARIN policy only /suggests/ that they use RFC 1918 space; they are allowed to get public space if they want it.
Right. But actually getting the space seems to be the issue since the only way space comes out is slow start /18 or immediate need /16? Is that right ?
This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.)
Agreed, but what's done is done. What /should/ have been done is now irrelevant.
Yes. Hind sight is 20/20... From bag phones to the iPhone, the evolution in cellular data has not been predictable.
And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.)
Presumably, they "need" to renumber out of 5/8 so that their customers can reach sites legitimately assigned addresses in 5/8.
However, those customers seem to have gotten along okay for years without public addresses, so why not renumber them into a second instance of 10/8? When I was in the consulting world, I had one customer with eight instances of 10/8, so I know it's doable.
Not always. Sometimes backend systems require customers use unique space, and that is really only the tip of that iceberg.... IMS does not work well with duplicate space.
If they want to give every customer a public address, IPv6 provides more than they could ever possibly use--and ~34M new IPv6 eyeballs would give the content industry a nice kick in the pants...
Yep. Sometimes I feel I personally preach and promote my ipv6 sermon too the point of being bothersome to the list. Apparently, my good word has not yet reached some. So, for all those that have considered ipv6 as the answer, I suggest you take the bold move of being part of the solution by ensuring your (and however you influence) phone does ipv6 on the cellular network. It is always good to lead by doing. On the T-Mobile USA network, the process is here https://sites.google.com/site/tmoipv6/lg-mytouch While I have not verified it myself, I hear the NEW gsm/umts galaxy nexus does ipv6 on 3g very well. http://www.newegg.com/Product/Product.aspx?Item=N82E16875176322 In all fairness, Verizon LTE has ipv6 as well. Regarding this thread in general, I asked a question about slow start and got a good answer about immediate need. Thanks ! Cb
S
-- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
In a message written on Thu, Dec 15, 2011 at 04:59:15PM -0800, Cameron Byrne wrote:
Regarding this thread in general, I asked a question about slow start and got a good answer about immediate need. Thanks !
Note that the "slow-start" is not based on size (as far as I can remember) but on timeframe. That is, if you have a bunch of ARIN blocks you can request a "12 month supply" based on past usage and best predictions. However, if your company has NO IPv4 space and you make your first request you get limited to 3 months worth of address space, 2nd request you get 6 months, and then 12 months with your 3rd and more requests. That's the slow-start. The feeling is that with no track record your predictions are, on average, less likely to be accurate. It's also my understanding that if you use all of the space you can immediately ask for more. Hypothetically, let's say ARIN gives a company with 34M subscribers a /18. Let's say said company can drop it in a DHCP server, and have 100% utilization in oh, a week. At the end of that week the company could submit documentation of 100% utilization to ARIN and get a second block, lather, since, repeat. It's part of the general "chinese buffet" model of ARIN, "Take all you want, but eat all you take." They want to see the eating part. So no, they won't hand you a /8 up front as a new entrant, but if you really can deploy (and document it) that fast you could get a /8's worth of space in a couple of months time. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Thu, 15 Dec 2011 18:43:05 -0500, Stephen Sprunk <stephen@sprunk.org> wrote:
However, if they actually have the number of hosts claimed, that justifies the space they're asking for. What addresses they're using today is irrelevant. ARIN policy only /suggests/ that they use RFC 1918 space; they are allowed to get public space if they want it.
Except they've tipped their hand already. If they've been NAT'ing 5/8 for who knows how long, it's clear they don't need public IPv4 space for their network. However, getting public space is easier than building multiple 10/8 private islands. (or so they thought :-))
However, those customers seem to have gotten along okay for years without public addresses, so why not renumber them into a second instance of 10/8? When I was in the consulting world, I had one customer with eight instances of 10/8, so I know it's doable.
And that's my entire point. Thus how they've failed to demonstrate a legitimate need for what little IPv4 space is still available. Maybe they (tmo) should get their european arm to ask RIPE for the entire 5/8 :-) (well, the 3/4th they haven't allocated yet.) --Ricky
On 12/15/11 3:31 PM, Ricky Beam wrote:
On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad <drc@virtualized.org> wrote:
... I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed.
That depends on how you see their "demontrated need." The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any "immediate need" on my (channeling ARIN) part. This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.)
And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.)
Heh, if this is about TMO, then they're squatting on alot more then just 5/8... My phone has an IP address in 22/8, and I've seen it get IPs in 25/8, 26/8 as well. I've always wondered what the deal was with the obviously squatted addresses that my device gets. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On Dec 15, 2011 10:35 PM, "Brielle Bruns" <bruns@2mbit.com> wrote:
On 12/15/11 3:31 PM, Ricky Beam wrote:
On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad <drc@virtualized.org> wrote:
... I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed.
That depends on how you see their "demontrated need." The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any "immediate need" on my (channeling ARIN) part. This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.)
And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.)
Heh, if this is about TMO, then they're squatting on alot more then just
5/8... My phone has an IP address in 22/8, and I've seen it get IPs in 25/8, 26/8 as well.
I've always wondered what the deal was with the obviously squatted
addresses that my device gets.
5/8 is not used for squat space in this case, somebody along this thread mentioned 5/8 as an example, not a data point. There's an effort to avoid squat space that appears in the dfz. Yes, that is a moving target. Cb
-- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
Jimmy, On Dec 14, 2011, at 11:14 PM, Jimmy Hess wrote:
A RFC1918 network is not a "normal" network; and this is not a renumbering in the same manner as a renumbering from public IP space to new public IP space.
I'll admit I haven't been following ARIN policy making for some time. Can you point to the ARIN policy that makes this distinction?
In other words: What is the technical justification that all those rfc1918 addressed hosts suddenly need to be moved immediately, and not over a normal allocation time frame for new public networks?
I used RFC 1918 space as an example. A more likely scenario is needing to renumber out of recently allocated squat space (particularly in situations where RFC 1918 is not an alternative).
That means the RIR has to establish that the criterion is good enough. "I have a rfc1918 /16 that I use, so give me a public /16, please" is not good enough.
That would essentially provide a backdoor around normal RIR justified need policy, if it were allowed......
Hmm. If one makes the assumption that the (1918/squat) address space is being used in an efficient manner and there is a business/technical requirement to renumber that space into public space, I would have thought the acceptance of justification would depend more on the business/technical requirement, not the fact that 1918/squat space is being used. Regards, -drc
On Wed, 14 Dec 2011, David Conrad wrote:
I'm confused. When justifying 'need' in an address allocation request, what difference does it make whether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumbering out of (say) RFC 1918 space into public space was still a justification for address space. Has this changed?
I tend to think of squatting in the sense of using a resource (could be an IP address block, could be an empty house, could be just about anything) that the person who is using it does not have permission to do so. I would think that definition holds up even when taking into account that people do not own their IP address allocations. An RIR or ISP assigning address space to a particular entity would establish a legitimate (but not irrevocable) claim to use a block of address space. Squatting is maybe one notch above hijacking in this sense. jms
On 12/15/2011 09:07, Justin M. Streiner wrote:
I tend to think of squatting in the sense of using a resource (could be an IP address block, could be an empty house, could be just about anything) that the person who is using it does not have permission to do so. I would think that definition holds up even when taking into account that people do not own their IP address allocations. An RIR or ISP assigning address space to a particular entity would establish a legitimate (but not irrevocable) claim to use a block of address space.
Squatting is maybe one notch above hijacking in this sense.
Well here's the thing about allocations. All an IP allocation is, is a entry in a data base saying an ORG has a right (from an RIR perspective) to use use an address range. Now a AS can actually use any IP space it wants internally, and if it gets another AS to accept their routes for that IP space and that AS's peers agree to accept those routes, the first AS can actually use that IP space. The RIR or IANA has zero legal authority to stop this as it's just a bunch of private networks agreeing on some one using IP space. Now this gets a lot more fun as we get closer to true IPv4 exhaustion. If there is a business case between two or more providers to side step a RIR process and recognize IP allocations that the RIR does not, who really has the power to stop them? Think about this, if you're a service provider in the US, and the big US networks agree to route your IP space that is actually registered to some network in Kazakhstan according to the RIR's, what will happen? from the service providers perspective the average user will have access to 99% of the US networks (which is really all people want :) and most likely half way decent connectivity to other AS's. Sure, this sucks, but 99% of the people don't care, and still provides better connectivity to services people want than IPv6 does. So follow the money and see how IPv4 exhaustion plays out ;) -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
On Dec 15, 2011, at 6:07 AM, Justin M. Streiner wrote:
On Wed, 14 Dec 2011, David Conrad wrote:
I'm confused. When justifying 'need' in an address allocation request, what difference does it make whether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumbering out of (say) RFC 1918 space into public space was still a justification for address space. Has this changed?
I tend to think of squatting in the sense of using a resource (could be an IP address block, could be an empty house, could be just about anything) that the person who is using it does not have permission to do so.
Right, but how does that impact whether or not non-squat space is justified? From my perspective, the actual bit patterns associated with an address in use shouldn't have any impact on the whether or not it is deemed by our ARIN overlords to be needed to be in use. Regards, -drc
In a message written on Wed, Dec 14, 2011 at 01:15:48PM -0800, Cameron Byrne wrote:
But all I can qualify for is a /18, and then in 3 months maybe a /17. This is called slow start ? For an established business?
https://www.arin.net/policy/nrpm.html#four216 You should be able to get a /16 under the "immediate need" policy if you can prove to ARIN you need it and can use it in 30 days or less. Otherwise, yes, the slow-start policies apply. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
participants (17)
-
Andrew D Kirch -
Brielle Bruns -
Bryan Fields -
Cameron Byrne -
David Conrad -
Jared Mauch -
Jeff Wheeler -
Jimmy Hess -
Joel jaeggli -
Justin M. Streiner -
Leo Bicknell -
Matthew Kaufman -
Ricky Beam -
Robert E. Seastrom -
Rubens Kuhl -
Stephen Sprunk -
Valdis.Kletnieks＠vt.edu