Hi, Op 25 jan. 2014, om 23:05 heeft Jeff Kell <jeff-kell@utc.edu> het volgende geschreven:

(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.

Sure, but the text I quoted is about ARIN allocations, so ARIN -> ISP. So the /28 is not provider-independent. It *is* the provider... And yes: I think this will become a mess in ARIN land :( Cheers, Sander

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

Hi Owen, Op 26 jan. 2014, om 05:36 heeft Owen DeLong <owen@delong.com> het volgende geschreven:

On Jan 25, 2014, at 13:59 , Sander Steffann <sander@steffann.nl> wrote:

...

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,

...

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

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

OK, then I'm sure it's been determined, but I can't really fault them for not announcing it yet.

?!?!? How are people supposed to prepare their filters for those tiny allocations if the corresponding prefix is not published? This is not making any sense... Sander

Regards Alexander Alexander Neilson Neilson Productions Limited alexander@neilson.net.nz 021 329 681 022 456 2326 On 26/01/2014, at 10:35 pm, Dave Bell <me@geordish.org> wrote:

...

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

http://tools.ietf.org/search/rfc6598

Correct me if I am wrong but this is the space reserved for internal use by providers for space for CGN systems that is not 1918 space so it doesn’t conflict with customers internal network IP Space. If I am correct the question is for which block has been reserved by ARIN for “address space for v6 devices they need to talk to v4 world” which is a globally unique allocation from their final /8 which they reference "Per policy, a /10 was reserved out of the last /8 to facilitate IPv6 deployment and that space is not included in our inventory count.” at https://www.arin.net/resources/request/ipv4_countdown.html which I think nobody has yet answered. Looking at 4.10 it doesn’t require the /10 block to be taken from their “Final /8” allocation (104/8) so I think it would be nice for someone from ARIN to come on here and confirm for all of us what the /10 is and ARIN’s thinking around the use of this space and their allocations being a max /24. Knowing the space now and whether larger transit providers will be issued it in /24’s for their transit customers which would mean they could announce the entire /24 and not require action from most AS’s or if the allocations will range in size directly to end users as standard issued space and ARIN asks us to accept it in our filters would be useful to know now so I can prepare the filters and it gives most AS’s time to implement this next large edit rather than make it a tweak when it begins to cause issues / issues are reported.

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

Sander Steffann wrote:

...

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.

The problem is not prefix length (it is a problem if >32, which is the case with IPv6) but the number of routes, which grows because of not fragmentation but poor way of multihoming through routing. Note that if IPv6 will be as popular as IPv4, it has almost equal number of routes for multihoming.

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.

Considering that a fast cheap 18bit 16M entry 1 chip SRAM has been available for many years, route vendors do not have to deploy slow and complicated logic for route look up, unless they want to make IPv4 route look up as slow as that of IPv6. Even 4G entry will not be a problem, except that it may cause BGP update computation slower. Masataka Ohta

Hi,

Op 27 jan. 2014 om 10:49 heeft Tore Anderson <tore@fud.no> het volgende geschreven:

* Sander Steffann

...

But more important: which /10 is set aside for this? It is not listed on https://www.arin.net/knowledge/ip_blocks.html

Probably 23.128/10:

arin||ipv4|23.128.0.0|4194304||reserved|

Now that is useful information! Can someone from ARIN confirm this? Cheers, Sander

On Jan 26, 2014, at 11:45 AM, John Levine <johnl@iecc.com> wrote:

...

I wonder what will change (if anything) when ARIN runs out of IPv4 space. The market in used IPv4 space will come out from the shadows,

It mostly has already done so in the APNIC and RIPE regions out of necessity.

and we'll see endless arguments between buyers of IPv4 space and ARIN, when ARIN refuses the updates to the address registry.

This would be "bad". I can think of few more effective ways of destroying the RIR system than by refusing to update the address registry. IMHO, the primary function of the Registries is to, you know, register. Not act as policy police, particularly of policies defined by a handful of folks who bother to participate in the ARIN public policy processes.

I don't see any reason for the people who run defaultless routers all over the world to change the /24 rule.

So IIUC, the theory goes that ISPs will be encouraged by their customers (upon pain of those customers becoming former customers) to announce their long prefixes, even though the ISPs will say "but nobody will listen". However, some ISPs _do_ listen (or rather, _don't_ filter) so the long prefix customers will get partial (i.e., worse than normal) reachability. Said customers will then whine at their ISPs saying "fix it!" and said ISPs will go to their peers and grovel, perhaps offering the Faustian bargain of "I'll accept yours if you accept mine and our respective customers will stop whining at us about each other". And then the apocalypse occurs. Or something like that. Regards, -drc

On Sun, Jan 26, 2014 at 8:02 PM, John R. Levine <johnl@iecc.com> wrote: I don't see ARIN recognizing bogus transfers in the registry -- if the transfer policy wasn't followed, then no transfer occurred.

Well, maybe. My vision is that the ISP calls up their upstreams and/or peers, some say OK, many say, sorry, unless you're offering to fund some very expen$ive router upgrade$, we can't do it. Even the ones who say OK will have little incentive to push their peers, so there will be flaky islands of routing.

The customer will continue to whine, of course, at which point the ISP has the bright idea to do some traceroutes and figure out which ISP announces the enclosing block. They call up that ISP and ask, what would you charge to tunnel that traffic back to us?

[snip]

If it's a /28 allocation under ARIN NRPM 4.10; there is no assignee that gets to announce the enclosing /24. I do not see in the cards, a lot of /28 allocations occuring. Since 4.10 addresses are exclusively for IPv6 transition, immediate need criteria must be met, and "the applicant must demonstrate that no other allocations or assignments will meet this need"; I doubt there will be a significant number of /28s that will fit the need. More likely, those that would utilize 4.10 will be asking for a /24 allocation, if addresses need to be routed. Or a /28; if the transition function where the addresses are required are small, and they do not require global reachability. Another answer for end users may well be.... instead of accepting /28s into your table: implement IPv6 instead, so you are not needing IPv4 to connect to these networks that have deployed IPv6 and are requiring the /28 for a special IPv4 to IPv6 transition purpose. -- -JH

I don't see ARIN recognizing bogus transfers in the registry -- if the transfer policy wasn't followed, then no transfer occurred.

do you share what you are smoking?

[...] particularly of policies defined by a handful of folks who bother to participate in the ARIN public policy processes

I love this part. "I was told a billion times where and how to participate in the policy debate - to the point where many people complain they are being told too many times - yet still did not 'bother' to participate. And now I am going to bitch and moan about the policy because, well, OTHER PEOPLE WROTE IT WITHOUT MY INPUT." Whot-EVA. ARIN is community owned & operated. You don't like it, fine, but don't complain when policies are turned out that you don't like if you don't even 'bother' to participate. -- TTFN, patrick On Jan 26, 2014, at 20:26 , David Conrad <drc@virtualized.org> wrote:

On Jan 26, 2014, at 11:45 AM, John Levine <johnl@iecc.com> wrote:

...

...

I wonder what will change (if anything) when ARIN runs out of IPv4 space. The market in used IPv4 space will come out from the shadows,

It mostly has already done so in the APNIC and RIPE regions out of necessity.

...

and we'll see endless arguments between buyers of IPv4 space and ARIN, when ARIN refuses the updates to the address registry.

This would be "bad". I can think of few more effective ways of destroying the RIR system than by refusing to update the address registry. IMHO, the primary function of the Registries is to, you know, register. Not act as policy police, particularly of policies defined by a handful of folks who bother to participate in the ARIN public policy processes.

...

I don't see any reason for the people who run defaultless routers all over the world to change the /24 rule.

So IIUC, the theory goes that ISPs will be encouraged by their customers (upon pain of those customers becoming former customers) to announce their long prefixes, even though the ISPs will say "but nobody will listen". However, some ISPs _do_ listen (or rather, _don't_ filter) so the long prefix customers will get partial (i.e., worse than normal) reachability. Said customers will then whine at their ISPs saying "fix it!" and said ISPs will go to their peers and grovel, perhaps offering the Faustian bargain of "I'll accept yours if you accept mine and our respective customers will stop whining at us about each other". And then the apocalypse occurs. Or something like that.

Regards, -drc