Re: De-bogon not possible via arin policy.

2011-12-16 Thread Cameron Byrne
On Dec 15, 2011 10:35 PM, Brielle Bruns br...@2mbit.com wrote:

 On 12/15/11 3:31 PM, Ricky Beam wrote:

 On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad d...@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



Re: De-bogon not possible via arin policy.

2011-12-15 Thread Justin M. Streiner

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



Re: De-bogon not possible via arin policy.

2011-12-15 Thread Bryan Fields
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



Re: De-bogon not possible via arin policy.

2011-12-15 Thread Matthew Kaufman

On 12/14/2011 11:14 PM, Jimmy Hess wrote:

On Wed, Dec 14, 2011 at 10:47 PM, David Conradd...@virtualized.org  wrote:
[snip]

I'm confused. When justifying 'need' in an address allocation request, what difference 
does it makewhether an address in use was allocated by an RIR or was squatted upon?  
Last I heard, renumberingout of (say) RFC 1918 space into public space was still a 
justification for address space.  Has thischanged?

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?


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




Re: De-bogon not possible via arin policy.

2011-12-15 Thread Valdis . Kletnieks
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.



pgpNweTOlbLBh.pgp
Description: PGP signature


Re: De-bogon not possible via arin policy.

2011-12-15 Thread David Conrad
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




Re: De-bogon not possible via arin policy.

2011-12-15 Thread David Conrad
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




Re: De-bogon not possible via arin policy.

2011-12-15 Thread Leo Bicknell
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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpBJfJyjezUh.pgp
Description: PGP signature


Re: De-bogon not possible via arin policy.

2011-12-15 Thread Matthew Kaufman

On 12/15/2011 8:05 AM, valdis.kletni...@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



Re: De-bogon not possible via arin policy.

2011-12-15 Thread Scott Weeks


--- br...@bryanfields.net wrote:
From: Bryan Fields br...@bryanfields.net

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?
--



The networking community in general.  The usefulness of the space would 
be very limited.

scott



Re: De-bogon not possible via arin policy.

2011-12-15 Thread Jimmy Hess
On Thu, Dec 15, 2011 at 10:53 AM, Matthew Kaufman matt...@matthew.at wrote:
 On 12/15/2011 8:05 AM, valdis.kletni...@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



Re: De-bogon not possible via arin policy.

2011-12-15 Thread Ricky Beam
On Thu, 15 Dec 2011 10:42:40 -0500, Matthew Kaufman matt...@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.)




Re: De-bogon not possible via arin policy.

2011-12-15 Thread David Conrad
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




Re: De-bogon not possible via arin policy.

2011-12-15 Thread Leo Bicknell
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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpS44ACx5Zz1.pgp
Description: PGP signature


Re: De-bogon not possible via arin policy.

2011-12-15 Thread Joel jaeggli
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.
 




Re: De-bogon not possible via arin policy.

2011-12-15 Thread Jeff Wheeler
On Thu, Dec 15, 2011 at 4:54 PM, Joel jaeggli joe...@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=nanogm=123406577704970w=4

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts



Re: De-bogon not possible via arin policy.

2011-12-15 Thread Stephen Sprunk
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
K5SSSdice at every possible opportunity. --Stephen Hawking



smime.p7s
Description: S/MIME Cryptographic Signature


Re: De-bogon not possible via arin policy.

2011-12-15 Thread Ricky Beam
On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad d...@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.)




Re: De-bogon not possible via arin policy.

2011-12-15 Thread Leo Bicknell
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=Samsung-t139,
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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpn3E5ssUUeh.pgp
Description: PGP signature


Re: De-bogon not possible via arin policy.

2011-12-15 Thread Matthew Kaufman

On 12/15/2011 2:32 PM, Leo Bicknell wrote:
It would only take a couple of these sorts of requests and the free 
pool is gone. 


Personally, I can't wait.

Matthew Kaufman



Re: De-bogon not possible via arin policy.

2011-12-15 Thread Valdis . Kletnieks
On Thu, 15 Dec 2011 14:32:17 PST, Leo Bicknell said:

 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.

/me makes some popcorn.  This could be fun.


pgpCZOCgqbO2T.pgp
Description: PGP signature


Re: De-bogon not possible via arin policy.

2011-12-15 Thread Joel jaeggli
On 12/15/11 14:12 , Jeff Wheeler wrote:
 On Thu, Dec 15, 2011 at 4:54 PM, Joel jaeggli joe...@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=nanogm=123406577704970w=4

I figured the discussion was for illustrative purposes more than anything.





Re: De-bogon not possible via arin policy.

2011-12-15 Thread Stephen Sprunk
On 15-Dec-11 16:31, Ricky Beam wrote:
 On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad d...@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
K5SSSdice at every possible opportunity. --Stephen Hawking



smime.p7s
Description: S/MIME Cryptographic Signature


Re: De-bogon not possible via arin policy.

2011-12-15 Thread Cameron Byrne
On Dec 15, 2011 6:43 PM, Stephen Sprunk step...@sprunk.org wrote:

 On 15-Dec-11 16:31, Ricky Beam wrote:
  On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad d...@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
 K5SSSdice at every possible opportunity. --Stephen Hawking



Re: De-bogon not possible via arin policy.

2011-12-15 Thread Leo Bicknell
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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpZLaBnu1JvJ.pgp
Description: PGP signature


Re: De-bogon not possible via arin policy.

2011-12-15 Thread Ricky Beam
On Thu, 15 Dec 2011 18:43:05 -0500, Stephen Sprunk step...@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



Re: De-bogon not possible via arin policy.

2011-12-15 Thread Brielle Bruns

On 12/15/11 3:31 PM, Ricky Beam wrote:

On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad d...@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



De-bogon not possible via arin policy.

2011-12-14 Thread Cameron Byrne
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 ?


Re: De-bogon not possible via arin policy.

2011-12-14 Thread Rubens Kuhl
 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



Re: De-bogon not possible via arin policy.

2011-12-14 Thread Andrew D Kirch

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



Re: De-bogon not possible via arin policy.

2011-12-14 Thread Robert E. Seastrom

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.li...@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 ?



Re: De-bogon not possible via arin policy.

2011-12-14 Thread David Conrad
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




Re: De-bogon not possible via arin policy.

2011-12-14 Thread Jimmy Hess
On Wed, Dec 14, 2011 at 3:15 PM, Cameron Byrne cb.li...@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



Re: De-bogon not possible via arin policy.

2011-12-14 Thread Joel jaeggli
On 12/14/11 18:46 , Jimmy Hess wrote:
 On Wed, Dec 14, 2011 at 3:15 PM, Cameron Byrne cb.li...@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
 




Re: De-bogon not possible via arin policy.

2011-12-14 Thread David Conrad
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




Re: De-bogon not possible via arin policy.

2011-12-14 Thread Jimmy Hess
On Wed, Dec 14, 2011 at 10:47 PM, David Conrad d...@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



Re: De-bogon not possible via arin policy.

2011-12-14 Thread Jared Mauch
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 mysi...@gmail.com wrote:

 
 That would essentially provide a backdoor around normal RIR justified
 need policy, if it were allowed..