On Wed, Jan 11, 2023, at 15:18, Marco Schmidt wrote:

Other IP ranges that might be used for IXP services, such as parts of an IPv4 allocation (ASSIGNED PA), do not fall under this condition.

So when the time comes (and provided the other conditions are met) it would be possible to request a /23 in grow an IXP currently using a /24 "ASSIGNED PA", with nothing to return to the NCC (the rest of the allocation being in use). Is that correct ? -- Radu-Adrian FEURDEAN

Dear David, On Wed, Jan 11, 2023 at 01:08:18PM -0600, David Farmer via address-policy-wg wrote:

Does the NCC's reverse DNS delegation tooling allow for a DNS delegation of a prefix longer than a /24?

Yes. See https://apps.db.ripe.net/docs/entire-documentation-(HTML)#description-of-the... "For IPv4 addresses, a dash is allowed in the fourth octet of the reverse address. This allows for reverse DNS delegations for address space that doesn't fall on octet boundaries as specified in RFC 2317. A dash is not allowed in any other octet." Example: To set up Reverse DNS for this IPv4 address range: 10.2.1.6 - 10.2.1.25 using the dash notation, the zone name becomes "6-25.1.2.10.in-addr.arpa" Kind regards, Job

Forgot to mention one thing, see below. (I am quoting my entire previous message so both can be replied to in-line at once.) * Tore Anderson

* Angela Dall'Ara

...

A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now available for discussion.

The goal of this proposal is to extend the lifetime of the IXP IPv4 address pool and to motivate IXPs to implement the exchange of IPv4 routing information over IPv6.

Hi,

This proposal is a step in the right direction, although I feel it should have gone further. I've already elaborated on why in the «IXP pool lower boundary of assignments» thread, so I don't seek to re-hash that whole thread, but for the record I'll repeat the gist of it in the formal proposal thread:

Since IPv4 is a finite resource that needs to last "forever", it seems wasteful to willfully assign too large prefixes to IXPs that do not need them. According to https://github.com/mwichtlh/address-policy-wg, a /26 would be excessively large for a majority of IXPs.

I would rather see a policy that did not specify a default size at all, but rather instructed the NCC to right-size each assignment according to the "at least 50% utilisation after a year" rule.

Note that this should not be considered an objection to this proposal, as I mentioned before it is a step in the right direction, after all.

With that out of the way, I have a few questions/comments:

1) Regarding «New IXPs will be initially assigned a /26 by default. Upon request, a /25 can be assigned initially. If the initial assignment has been utilised by at least 50%, IXPs can request the assignment of a /24»:

This is somewhat difficult to decipher. Does it mean that:

a) a new IXP can simply ask for an initial /25 and receive it, no questions asked? b) an existing IXP that has used 50% of an initial /26 will be able to upgrade straight to a /24, i.e., bypassing a /25? (Or even %50-of- /27→/24, in an unlikely but not impossible corner case.)

To improve clarity, I would suggest not to mix the conditions for new IXPs / initial assignments with the conditions for already existing IXPs that seek to upgrade a previous assignment.

2) Regarding «Assignments strictly larger than a /24 will only be made to IXPs that offer the exchange of IPv4 routing information over IPv6 at their route servers»:

a) What is the purpose / meaning of the word «strictly» here? I assume it is there for a reason, but removing it does not seem to me to change the meaning of the sentence in any way (but then again, I am not a native English speaker).

b) Depending on whether one considers an assignment from the NCC to the IXPs as to be a continuous state or as a one-time event, this may cause an instant obligation on current holders of larger-than-/24 IXP prefixes to implement IPv4-over-IPv6 routing in their route servers. Is that the intention?

3) Regarding «On request or once there are no more available assignments of /26 (or larger), assignments can be made down to /27.»: I suggest this proposal adds the current (and future) non-assignable «space dust» (prefixes smaller than /24) in the NCC's inventory to the IXP pool. Considering that IXPs is one of the few use cases where this «space dust» is useful, and that this proposal opens up for assignments of such small prefixes from the IXP pool, it seems logical to open up for the similar use of the small prefixes currently not part of the IXP pool as well. However, when we are at at a point in time where the IXP pool is completely empty except for such «space dust», why restrict the assignment size to /27? It seems to me that if we have reached a point in time where the only thing remaining in the IXP pool is «space dust» smaller than /27, and there is a small new IXP that could make use of, say, a /28, I see no reason to deny the IXP receiving that assignment. Therefore I suggest replacing «assignments can be made down to /27» with «smaller assignments can be made» or something along those lines. Tore

* Wolfgang Tremmel

...

...

...

a) a new IXP can simply ask for an initial /25 and receive it, no questions asked?

yes. But if a new IXP requests an initial /25 they at least have done some homework about what to expect. And I expect that homework to be shown to the RIPE NCC to get the /25.

What makes you expect any "homework" to be shown to the RIPE NCC, if the policy says they can have the /25, no questions asked? The policy needs to explicitly state that such "homework" is necessary if that is what you want.

...

...

b) an existing IXP that has used 50% of an initial /26 will be able to upgrade straight to a /24, i.e., bypassing a /25? (Or even %50-of- /27→/24, in an unlikely but not impossible corner case.)

Also yes. If the IXP grows really fast, they can go directly to a /24. Why? Renumbering an IXP is pain. A lot of pain. I  (personally) have run renumbering projects or participated in renumbering projects multiple times.

Wouldn't that mean that the policy can be gamed? Procedure: 1. Request and receive an initial /27 (permitted by new section 8) 2. Reach 50% utilisation (12 members + 2 RSes + net/bcast addrs) 3. Request and receive a replacement /24 This "land-grabbing" IXP has now gotten its hands on a /24 while only at 6.25% utilisation. Nothing in the proposed policy will prevent this from happening, as far as I can tell. Should it?

...

...

2) Regarding «Assignments strictly larger than a /24 will only be made to IXPs that offer the exchange of IPv4 routing information over IPv6 at their route servers»:

a) What is the purpose / meaning of the word «strictly» here? I assume it is there for a reason, but removing it does not seem to me to change the meaning of the sentence in any way (but then again, I am not a native English speaker).

idea is: strictly larger > larger >=

Hm. I do believe «larger» means ">", not ">=". Maybe a native speaker could confirm. If so, «strictly» could and should be dropped as it only serves to add confusion.

...

However, when we are at at a point in time where the IXP pool is completely empty except for such «space dust», why restrict the assignment size to /27? It seems to me that if we have reached a point in time where the only thing remaining in the IXP pool is «space dust» smaller than /27, and there is a small new IXP that could make use of, say, a /28, I see no reason to deny the IXP receiving that assignment.

IMHO a /28 is not useful for an IXP. Or what I consider to be an IXP.

According to https://github.com/mwichtlh/address-policy-wg about 40% of all IXPs would fit in a /28 «with 50% oversubscription», and about 55% all IXPs would fit in a /28 with no oversubscription. I therefore think you might consider adjusting your perception of what an IXP is. Alternatively we would need to consider the supporting data for this proposal bogus. In any case, if the requesting new IXP gets offered a /28 (as that is all that is available at that point), it is of course free to decline. There is no harm in having the NCC make the offer, is there?

We can do that once the pool is empty in another policy change IMHO.

Why wait? What is the harm in doing it now? Tore

* Matthias Wichtlhuber

regarding 6.1(4) - (default is /26, /25 is handed out upon request):

The idea behind this part of the proposal is that there are two kinds of IXPs, one that is founded due to the need to interconnect a few networks in a specific region and no intent of growth and one that is operated with the explicit intent to grow and generate business. IXPs can decide on their plans on their own and do an appropriate selection of their initial assignment.

That places a big trust in the new IXPs to not ask for a /25 if they do not need it. To me, that seems naive - there are strong incentives for new IXPs to ask for as much as possible regardless of actual need. You point them out in the proposal yourself: avoid and/or postponing future renumbering and IPv4 purchases. A similar situation exist in IPv6. LIRs can freely choose initial allocations in the range /29../32. I bet the vast majority of new LIRs do not need anything larger than /32 (they definitively do not have to worry about renumbering or IPv6 purchases), yet in 2022 the numbers were: 1035 /29 allocations 3 /30 allocations 0 /31 allocations 64 /32 allocations So 94% chose the biggest they could get. That's human nature for you. Under the proposed policy I bet you will see the same thing happening, most IXPs will ask for /25s. (I sure would, if I was to start an IXP. There is simply no reason not to.)

regarding 6.1 (7) - (assignments down to /27):

I agree that the policy can be gamed by asking for a /27 and jumping to a /24; we might consider to restrict this part to only handing out /27s once the IXP pool is depleted, but not upon request. I doubt RIPE has handed out any /27 assignments upon request anyways; maybe someone from RIPE can look into this?

For what it is worth there are currently 32 /27 assignments in the delegated file (52 assignments /27 and smaller), but none of them are from the IXP pool. (They could still be used by IXPs though.) In fact, there are exactly 0 assignments smaller than /24 made from the IXP pool, even though the policy allows for this. This makes me even more convinced that IXPs will generally chose to take the largest prefix policy allows them to.

regarding the general point of lower bound of assignments and your comment:

...

Alternatively we would need to consider the supporting data for this proposal bogus.

As I have stated a couple of times in the previous discussions, the data in PeeringDB can only provide a lower bound of connections per IXP; nevertheless it remains the best dataset we currently have. Thus the decision will have to be a mix of listening to experienced people from the IXP community and the results of the analysis. I think a /26 is a good compromise here.

I was not trying to restart that part of the discussion. We can agree to disagree on whether or not /26 is a good value, and leave it at that. (It's better than /24, we can agree on that.) However, this comment was made in the context of my proposal of adding the «IPv4 space dust» to the IXP pool, for use when the pool runs out of /26s. The NCC inventory currently contains 47+ blocks in the range /29../25 that *would* have been perfectly usable for assignment to IXPs, but they can not be assigned to IXPs under this policy because they are not part of the specially designated /15 IXP pool. I say let's add them, so they actually can do some good, instead of rotting away in the NCC inventory. This «IPv4 space dust» also includes some prefixes smaller than /27, which would not be assignable under the proposed policy even if had added the «IPv4 space dust» to the IXP pool. However, there *are* small IXPs that could potentially have used these. There are multiple examples just here in Norway: Trondheim IX: 5 members Bergen IX: 6 members Tromsø IX: 3 members Stavanger IX: 8 members Source: https://www.nix.no/who-is-connected/ (bottom of page) All of them would make do with a /28, and three out of four would make do with a /29. I would further note that these are not newly started IXPs experiencing rapid growth, they are well established. In my opinion, denying a small IXP similar to these the opportunity to receive a small assignment – especially when such small prefixes are the only ones left in the NCC's inventory – just because some folks from DE-CIX do not «consider [it] to be an IXP» just seems cruel. I do not see any harm whatsoever in allowing their assignment. Tore

Hi Nick,

As far as I understand, this protocol is not widely deployed in IXPs, nor is it widely tested in inter-AS production environments. It would be concerning if an untested protocol were mandated as a production requirement in a RIR addressing policy document.

Before continuing down this path, could the authors provide information on how this protocol works in production environments?

This part of the proposal is intended to foster the adoption of the technology. IXPs may offer it as beta or experimental while still doing the actual exchange of traffic via standard BGP over IPv4. We are aware this is part controversial; we can remove it if the community thinks this is a bad idea. Matthias -- Dr.-Ing. Matthias Wichtlhuber Senior Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber@de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ------------------------------ DE-CIX 25th anniversary: Without you the Internet would not be the same! Join us on the journey at https://withoutyou.de-cix.net ________________________________________ Von: address-policy-wg <address-policy-wg-bounces@ripe.net> im Auftrag von Nick Hilliard <nick@foobar.org> Gesendet: Dienstag, 7. Februar 2023 12:01:24 An: Angela Dall'Ara Cc: RIPE Address Policy Working Group Betreff: Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) Angela Dall'Ara wrote on 09/01/2023 10:40:

As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer.

not sure if this comment is in time, but the text contains:

Assignments strictly larger than a /24 will only be made to IXPs that offer the exchange of IPv4 routing information over IPv6 at their route servers

As far as I understand, this protocol is not widely deployed in IXPs, nor is it widely tested in inter-AS production environments. It would be concerning if an untested protocol were mandated as a production requirement in a RIR addressing policy document. Before continuing down this path, could the authors provide information on how this protocol works in production environments? Nick -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

On Wed, Feb 8, 2023 at 9:24 AM Sander Steffann <sander@steffann.nl> wrote:

Now, I totally understand the chicken and egg problem here: as long as IXPs get IPv4 addresses there will be no need to exchange IPv4 routing information over IPv6. But until that has been properly tested we continue to give them IPv4 space. But let’s not put in artificial restrictions to make them test it. If the real reason is that we don’t have enough IPv4 space to give to IXPs in the future, then let’s make *that* clear.

Like: “From <insert-cutoff-date-here> IXPs will no longer be able to grow their IPv4 assignment beyond <insert-prefix-size-here>. IXPs that anticipate needing to grow larger than this are strongly encouraged to start testing with exchanging IPv4 routing information over IPv6”.

The cutoff date may be a little arbitrary (I’m sure the NCC can give reasonable predictions to base it on) but at least it matches with reality :)

I generally support the idea above. However, reviewing this and the previous thread leading up to this policy proposal, I haven't seen any projected runout dates for the current IXP pool. Therefore, can we get projected runout dates based on the current and proposed minimum IXP allocation sizes? We can use that to inform the selection of a date in the above suggestion, presumably picking a date sometime short of the projected runout. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Matthias Wichtlhuber wrote on 08/02/2023 13:36:

This part of the proposal is intended to foster the adoption of the technology. IXPs may offer it as beta or experimental while still doing the actual exchange of traffic via standard BGP over IPv4.

Hi Matthias, this is premature: if the protocol didn't work well in production environments, that would raise questions about the wisdom of mandating the protocol in the first place. In any event, as Randy pointed out, it's generally not a good idea to use policy in one area to try to force specific technology choices in another. Nick

Hi, On Thu, Feb 09, 2023 at 08:23:27AM +0000, Matthias Wichtlhuber wrote:

Hi Nick, Randy, David, Sander, (all,)

agreed, we will remove this part from the proposal.

I actually do like this push, and it's not the first time we've done policy to push "non-progress" elsewhere (32 bit ASNs "by default"). OTOH, without this clause, IXPs will notice "there is no more IPv4 space, so maybe we need to do something else", and then it will be a bit late to start researching - so maybe this is something people from the IXP community (EuroIX?) can start working on, *together with the usual vendors*, to make sure this stuff actually works when the IXPs need it, and there is good documentation for the IXP members "how to make it work on their gear"... gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Thu, Feb 09, 2023 at 09:01:49AM +0000, Wolfgang Tremmel wrote:

AS196610 is happy to take peers at any exchange I am present to try this out.

I already have it working on two private connections. It works, it just can be awkward to configure (on my side, its just a tag in peering manager to set it up)

I also have a slide deck ready to explain it. Video will be next. Get Popcorn.

Impressive! :-) Looking forward to the slide deck, especially to the section "on vendor X, you need yz... to make it work" (and/or "vendor Z does not understand what we want them to do"...). gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Thu, Feb 09, 2023 at 10:52:15AM +0000, Nick Hilliard wrote:

We're no longer in a world where it's viable to deploy untested and experimental L3 packet forwarding features in IXPs. NISD2 is just around the corner, which will categorise all IXPs in the EU region as Essential Entities - the equivalent of Operators of Essential Services in NISD1. I.e. IXPs will shortly be regulated entities.

I hear you, but that argument can be twisted around into "why are you not permitting access to new market entrants to your IXP? don't tell me stories about 'no IPv4 addresses for the fabric', you had enough time to prepare"... So, if there are no more v4 addresses in the RIPE NCC IXP pool, some unpleasantness will ensue, no matter what. (But I do agree that "testing and education" can be done nicely outside the policy) gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

-----Original Message----- From: address-policy-wg <address-policy-wg-bounces@ripe.net> On Behalf Of Shane Kerr Sent: Wednesday, February 8, 2023 5:35 PM To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) <snip/>

If I recall correctly, the original motivation of the IXP policy was to allow IXP to get space, even if they did not otherwise qualify to become an LIR. This was so that they could maintain independence from LIR peering at the IXP.

However, there are basically no restrictions on becoming an LIR, and basically no space available. So there is no reason for a special IXP policy.

My own preference is that we stop IXP IPv4 assignments completely. IXP can purchase IPv4 space on the open market the same as everyone else.

Shane

I don't typically comment on address policy because it might look self-serving, but someone asked me to comment. Thinking about the costs to set up an IXP, I went back to this RIPE presentation a few years ago: "The $1,000 Internet Exchange" https://ripe71.ripe.net/presentations/30-1000-dollar-exchange-ripe71.pdf Market price for a /24 might be high enough to prevent an IXP from forming. Even a significant subnet might be expensive, and that's if someone was willing and able to sell a /26. Lee