Yeah, its been a while since I had to get involved in this. We have a
customer with their own IPv4 allocation that wants us to announce a /27 for
them. Back in "the day", it was /24 or larger or all bets were off. Is
that still the case now?
Things haven't changed. /24 is the smallest IPv4 prefix many providers will accept.
jms
/24 hasn't changed and is not likely to.
~Seth
Yes, a /27 is too small. You need at least a /24.
yes.
Hi,
Yeah, its been a while since I had to get involved in this. We have a
customer with their own IPv4 allocation that wants us to announce a /27 for
them. Back in "the day", it was /24 or larger or all bets were off. Is
that still the case now?
This is still the case today.
I wonder what will change (if anything) when ARIN runs out of IPv4 space. Geoff's current predictions say Feb 2015, but I wouldn't be surprised if it turns out to be sooner than that. But, when that happens ARIN will only have the 'Dedicated IPv4 block to facilitate IPv6 Deployment' [1] left, and it will use 'a minimum size allocation of /28 and a maximum size allocation of /24' for that block. The block is meant for things like dual stacked DNS servers, NAT64 and other IPv6 deployments where a bit of IPv4 is still necessary.
I wonder how reachable those systems will be... Will people adjust their filters, or will most usage of this block (and thereby all new entrants in the ISP market in the ARIN region) just be doomed?
Cheers,
Sander
(snip)
I doubt that anything > /24 will ever be eligible as a "portable"
provider independent block. If within a provider, you can slice and
dice as you wish.
Jeff
Hi,
I would imagine this should be announced with the larger block owner.
There aren't any /27 or /28 Allocations from ARIN to an ISP....
A /28 is longer than the ARIN Minimum allocation block size of /22, and
longer than the minimum transfer size of a /24 block.
Hi Jimmy,
There aren't any /27 or /28 Allocations from ARIN to an ISP....
A /28 is longer than the ARIN Minimum allocation block size of /22, and longer than the minimum transfer size of a /24 block.
Now: yes. Soon: no. Read https://www.arin.net/policy/nrpm.html#four10
Sander
That's actually may not be the best question. That block will come from within a specific prefix and I suspect that ISPs and the like will adjust their filters FOR THAT PREFIX.
Consider the possibility of a policy change which allows the transfer of smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN policy is not immutable, we have a policy development process so that anyone who wants to can start the process of changing it.)
Owen
Hi Owen,
Hi,
[…] But, when that happens ARIN will only have the 'Dedicated IPv4 block to facilitate IPv6 Deployment' [1] left, and it will use 'a minimum size allocation of /28 and a maximum size allocation of /24' for that block. The block is meant for things like dual stacked DNS servers, NAT64 and other IPv6 deployments where a bit of IPv4 is still necessary.
I wonder how reachable those systems will be... Will people adjust their filters, or will most usage of this block (and thereby all new entrants in the ISP market in the ARIN region) just be doomed?
That's actually may not be the best question. That block will come from within a specific prefix and I suspect that ISPs and the like will adjust their filters FOR THAT PREFIX.
Same question… Will people adjust their filters, (even if only for that prefix)? All over the world? I think 'will adjust their filters for XYZ' is highly optimistic, but let's hope it will work, otherwise the ISPs in the ARIN region will have a problem. (Or maybe not: existing ISPs (for who a /2[4-8] is not a significant amount) might not mind if a new competitors only gets a /2[5-8] that they cannot route globally. But I really hope it doesn't come to that.)
But more important: which /10 is set aside for this? It is not listed on https://www.arin.net/knowledge/ip_blocks.html
Consider the possibility of a policy change which allows the transfer of smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN policy is not immutable, we have a policy development process so that anyone who wants to can start the process of changing it.)
I’m well aware of that, but I’ll stick to RIPE policies for now 
Cheers,
Sander
Hi Owen,
Hi,
[…] But, when that happens ARIN will only have the 'Dedicated IPv4 block to facilitate IPv6 Deployment' [1] left, and it will use 'a minimum size allocation of /28 and a maximum size allocation of /24' for that block. The block is meant for things like dual stacked DNS servers, NAT64 and other IPv6 deployments where a bit of IPv4 is still necessary.
I wonder how reachable those systems will be... Will people adjust their filters, or will most usage of this block (and thereby all new entrants in the ISP market in the ARIN region) just be doomed?
That's actually may not be the best question. That block will come from within a specific prefix and I suspect that ISPs and the like will adjust their filters FOR THAT PREFIX.
Same question… Will people adjust their filters, (even if only for that prefix)? All over the world? I think 'will adjust their filters for XYZ' is highly optimistic, but let's hope it will work, otherwise the ISPs in the ARIN region will have a problem. (Or maybe not: existing ISPs (for who a /2[4-8] is not a significant amount) might not mind if a new competitors only gets a /2[5-8] that they cannot route globally. But I really hope it doesn't come to that.)
Realistically, anyone depending on IPv4 is going to has a growing problem which will only continue to grow.
But more important: which /10 is set aside for this? It is not listed on https://www.arin.net/knowledge/ip_blocks.html
I'm not sure it has been determined yet, let alone announced.
Consider the possibility of a policy change which allows the transfer of smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN policy is not immutable, we have a policy development process so that anyone who wants to can start the process of changing it.)
I’m well aware of that, but I’ll stick to RIPE policies for now
I admit I'm not familiar with the details of the RIPE policy in this regard. Do they allow longer prefixes to be transferred and/or acquired?
I will point out that the NA in NANOG mostly refers to the ARIN region.
Owen
Hi Owen,
Same question… Will people adjust their filters, (even if only for that prefix)? All over the world? I think 'will adjust their filters for XYZ' is highly optimistic, but let's hope it will work, otherwise the ISPs in the ARIN region will have a problem. (Or maybe not: existing ISPs (for who a /2[4-8] is not a significant amount) might not mind if a new competitors only gets a /2[5-8] that they cannot route globally. But I really hope it doesn't come to that.)
Realistically, anyone depending on IPv4 is going to has a growing problem which will only continue to grow.
Yes, but those last IPv4 addresses are for ISPs who work with IPv6 and need a little bit of IPv4 to communicate with the legacy world. If they can't even do that it will be extra hard (impossible?) for them to function.
But more important: which /10 is set aside for this? It is not listed on https://www.arin.net/knowledge/ip_blocks.html
I'm not sure it has been determined yet, let alone announced.
According to https://www.arin.net/resources/request/ipv4_countdown.html phase one it should have been done in September 2012: 'IPv4 address space required for NRPM 4.10, which sets aside a contiguous IPv4 /10 block to facilitate IPv6 deployment, was reserved and removed from the remaining IPv4 address pool.' I can't find anything more specific though...
Consider the possibility of a policy change which allows the transfer of smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN policy is not immutable, we have a policy development process so that anyone who wants to can start the process of changing it.)
I’m well aware of that, but I’ll stick to RIPE policies for now
I admit I'm not familiar with the details of the RIPE policy in this regard. Do they allow longer prefixes to be transferred and/or acquired?
Allow: yes. Anybody doing that for globally routable purposes: no. Although it can be used for networks that don't need to be in the global BGP table.
I will point out that the NA in NANOG mostly refers to the ARIN region.
??? No idea what this comment is supposed to mean. You may find this weird, but since the Internet is actually a global network I do care about what happens in NA...
Cheers,
Sander
But more important: which /10 is set aside for this? It is not listed on
https://www.arin.net/knowledge/ip_blocks.html
100.64/10
sander,
i suspect that, as multi-homing continues to grow and ipv4 space
fragments to be used in core-facing nat[64]-like things, a decade from
now we'll see the boundary move to the right.
randy
Regards
Alexander
Alexander Neilson
Neilson Productions Limited
alexander@neilson.net.nz
021 329 681
022 456 2326
Hi,
Hi Randy,
i suspect that, as multi-homing continues to grow and ipv4 space
fragments to be used in core-facing nat[64]-like things, a decade from
now we'll see the boundary move to the right.
Maybe, if the equipment can handle the number of routes. I actually see two opposing things: the scarcity will require more fragmentation with smaller fragments, which requires less strict filtering. On the other hand the fragmentation will already start with e.g. /20s being fragmented into /24s. That might already cause problems for current hardware, which might cause people to filter more strictly. Unfortunately my crystal ball is broken at the moment.
When ARIN starts allocating /28s from the reserved /10 in ±12 months I wonder which direction it will go... I hope for the ARIN region that the majority of operators globally will loosen up their filters for at least that /10 within those 12 months so the allocations will actually be usable. For that to happen it would be very useful to know *which* /10 has been reserved in 2012 though... 12 months is not much for global communication, education and filter adjustments.
And anyway, who needs IPv4 a decade from now? 
Cheers,
Sander