[arin-ppml] Feedback on ARIN 53 question on micro-allocations for IXPs
Tyler O'Meara
arin at tyleromeara.com
Mon Apr 22 19:47:25 EDT 2024
To make this discussion concrete, I've written a quick proposed text below at
the end of this email. The main changes I made:
* Removed the term "micro-allocation", as /24s are now the default allocation.
* Moving the section granting gTLD operators justification of a /23 to a
different section
* Removal of the paragraph specifying a specific block for IX allocations
* Addition of a specific requirement for 4.4 addresses to be used solely for
operating critical infrastructure
The following bullet point is the only part of this change that has any policy
impact, and as noted in this thread, I expect the actual change to be a no-op.
All I'm doing is closing a loophole in the written text that currently allows an
operator of CII to get an allocation under 4.4 to then go off and use it for
some other purpose. In practice, I expect ARIN staff would prohibit that today,
but by my reading of 4.4, merely being an operator of CII gives one carte-
blanche to 4.4 space (which is surely not the intention).
4.4 Allocations for Critical Internet Infrastructure
4.4.1 Critical Internet Infrastructure
ARIN allocates IPv4 addresses to operators of Critical Internet Infrastructure.
Critical Internet Infrastructure includes, but is not limited to, public
exchange points, core DNS service providers (e.g. ICANN-sanctioned root and
ccTLD operators), RIRs and the IANA.
gTLDs are not considered Critical Internet Infrastructure under this section.
Qualification under this section does not preclude an organization from
requesting Internet Number Resources under any other applicable policy.
4.4.2 Minimum Assignment
ARIN's minimum assignment for Critical Internet Infrastructure is a /24.
4.4.3 Exchange Point Requirements
Exchange point operators must provide justification for the allocation,
including: connection policy, location, other participants (minimum of three
total), ASN, and contact information.
4.4.4 Reserved Pool
ARIN will place an equivalent of a /15 of IPv4 address space in reserve solely
for allocation under this section.
4.4.5 Use for Critical Internet Infrastructure only
IPv4 Addresses under this section are to be used solely in support of operating
Critical Internet Infrastructure.
---
Somewhere else in the NRPM (probably somewhere in 4.3):
ICANN-sanctioned gTLD operators receive an automatic justification for the
equivalent of an IPv4 /23 block for each authorized gTLD. This limit of a /23
equivalent per gTLD does not apply to gTLD allocations made under previous
policy.
On Mon, 2024-04-22 at 19:49 -0300, Fernando Frediani wrote:
>
> Of course Owen, on every email I read from you I get the impression that if it
> was up to you there would be no need for RIRs and policies to exist or maybe
> to be conservative in this impression you seem to like of the RIRs as a simple
> bookeeper with no power to enforce anything, even what the community who
> develops the policies set as reasonable.
>
>
> It is of course up to the RIR, has always been and hopefully will continue to
> be, to dictate certain things which some private ones keeps refusing to comply
> because take out their freedom to do what they like with something doesn't
> belong to them. Simply if something is not in line with a policy set by this
> forum it is up to the RIR to dictate something that may not be desired by
> someone. I know that it may not be good for certain kind of business but life
> is not fair in many ways. So, just save up from recurring to this old useless
> mantra.
>
>
> It doesn't matter if an IXP have abused or not. What I am putting is there
> should be well defined rules on how resources can be used and not allow this
> continuous "rule-less party desire" go just because it may hit someone's
> desire to take advantage of the system.
> Fernando
>
>
> On 22/04/2024 16:57, Owen DeLong wrote:
>
>
> > I’m not the one who is mixed up here. I know exactly what the policy
> > intent was, I was very involved in creating the policy.
> >
> >
> >
> > IXPs are meant to provide value to the peers which gather at the IXP by
> > facilitating the efficient delivery of traffic amongst participants in the
> > IXP. One way to do that is direct peering relationships through the IXP
> > fabric. However, that is not the only valid mechanism for doing so.
> > Additional services such as route servers, caches, etc. can also bring value
> > to participants and it is not the role of the RIRs to dictate to IXPs which
> > of those particular things are or are not valid use of the IXPs addressing.
> >
> >
> >
> >
> > My point is that I do not know of any IXPs currently abusing their addresses
> > for any of the purposes you stated would occur.
> >
> >
> >
> >
> > I’m not supporting or proposing any change to current IXP related policy.
> > I’m stating that the policy is sufficient as is.
> >
> >
> >
> >
> > You are the one arguing for a change. That change is not, IMHO, supported by
> > the record and multiple other people have commented on the potential harmful
> > effects of a change.
> >
> >
> >
> >
> > As such, I fail to see how you can claim I am arguing for a more flexible
> > scenario. I. am arguing to preserve the status quo.
> >
> >
> >
> >
> > Owen
> >
> >
> >
> >
> >
> > >
> > > On Apr 21, 2024, at 22:45, Fernando Frediani <fhfrediani at gmail.com> wrote:
> > >
> > >
> > >
> > >
> > > It seems you kind of disregards the basics of IP assignment and mix up
> > > things and what they were made for and thought for. It is not because
> > > something looks convenient, that is something right. When conveniences
> > > prevail over the main point we start to miss the discussion propose. What
> > > you are saying below looks more a personal preference if you were in
> > > charge of an IX to make it develop than what is the main point of the
> > > discussion how resources from a special pool should be treated.
> > > IXPs are not Broadband Services Providers nor RIRs and are not meant to
> > > distribute IP space to anyone. IXPs need the IPs to build its core
> > > services in order to interconnect ASNs locally. Organizations connecting
> > > to an IXP have the ability to go directly to the RIR and get resources
> > > from there through different ways and that's how it should continue.
> > >
> > > Fernando
> > >
> > >
> > > On 22/04/2024 00:06, Owen DeLong wrote:
> > >
> > >
> > > > A small probability of abuse is generally not seen as a reason to deny
> > > > legitimate users.
> > > >
> > > >
> > > >
> > > > I think we can generally count on IXPs not to distribute large portions
> > > > of their resources to cache providers that do not bring significant
> > > > value to the users of the IX with those resources. To the best of my
> > > > knowledge, there is no problem of abuse to date. As such, I think your
> > > > concern here has about as much credibility as those crying about
> > > > election fraud in the US.
> > > >
> > > >
> > > >
> > > >
> > > > Owen
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > On Apr 18, 2024, at 22:31, Fernando Frediani <fhfrediani at gmail.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > By doing this it creates a short path to some specific type of
> > > > > Internet companies over the others to have access to scarce resources
> > > > > via someone else's right (the IX) to request those addresses for the
> > > > > minimum necessary to setup an IX, not to 'give a hand' to third
> > > > > parties. It would start to distort the purpose of the pool.
> > > > >
> > > > >
> > > > > Content providers members are members like any other connected to that
> > > > > IX. Why make them special to use these resources if other members
> > > > > (e.g: Broadband Internet Service Providers) connected to that same IX
> > > > > cannot have the same privilege ?
> > > > > They and any other IX member, regardless of their business, can get
> > > > > their own allocations with their own resources.
> > > > >
> > > > > Fernando
> > > > >
> > > > >
> > > > > On 19/04/2024 02:13, Owen DeLong wrote:
> > > > >
> > > > >
> > > > > > I think that if it’s a cache that is serving the IX (i.e. the IX
> > > > > > member networks) over the IX peering VLAN, that’s perfectly valid.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Owen
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > On Apr 18, 2024, at 20:35, Fernando Frediani
> > > > > > > <fhfrediani at gmail.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 18/04/2024 21:34, Matt Peterson wrote:
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > <clip>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > If the policy needs revision (John's comments did not provide
> > > > > > > > enough of a background story - it's unclear if this a yet
> > > > > > > > another IPv4 land grab approach, and/or IXP's evolving into
> > > > > > > > hosting content caches, and/or the historical industry
> > > > > > > > acceptable usage that Ryan shares), maybe consider micro-
> > > > > > > > allocations for IXP usage as unannounced prefixes and for routed
> > > > > > > > prefixes, an IXP applies under NRPM 4.3 (end user assignments).
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > I have a similar conversation recently with someone willing to use
> > > > > > > IXP allocations to assign to content caches and on this point I
> > > > > > > think that IXP pool should not be for that. Even knowing the
> > > > > > > positive impact a hosted content directly connected to a IXP makes
> > > > > > > it is their business to being their own IP address not the IXP and
> > > > > > > to be fair if you think of any CDN service they all have total
> > > > > > > means to do that. Therefore IXP allocations should be used for IXP
> > > > > > > own usage, so internal Infrastructure and to connect members and
> > > > > > > things should not be mixed up.
> > > > > > >
> > > > > > >
> > > > > > > Regards
> > > > > > > Fernando
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --Matt
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > ARIN-PPML
> > > > > > > > You are receiving this message because you are subscribed to
> > > > > > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > > > > > Unsubscribe or manage your mailing list subscription at:
> > > > > > > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > > > > > > Please contact info at arin.net if you experience any issues.
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > ARIN-PPML
> > > > > > > You are receiving this message because you are subscribed to
> > > > > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > > > > Unsubscribe or manage your mailing list subscription at:
> > > > > > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > > > > > Please contact info at arin.net if you experience any issues.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > ARIN-PPML
> > > > > You are receiving this message because you are subscribed to
> > > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > > Unsubscribe or manage your mailing list subscription at:
> > > > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > > > Please contact info at arin.net if you experience any issues.
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > ARIN-PPML
> > > You are receiving this message because you are subscribed to
> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > >
> > >
> >
> >
> >
> >
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML
mailing list