Hi
On 18/12/2023 17:34, Owen DeLong wrote:
<clip>
ike the idea of shrinking IPv4 delegations form RIRs below /24, but if
that is the feasible option than better than nothing.
My point is don’t shrink it, let it roll at /24 until it runs out. Once it
does, IXPs are the least disadvantaged by this fact of virtually any network
users because (in theory) an IXP language is used only to exchange routing
information and forward traffic. Since BGP fully supports deliverability of
IPv4 NLRI over IPv6 peering sessions and IPv4 packets can be subsequently
delivered without requiring IPv4 on the router interfaces on the IXP, despite
traditional mindset, there’s no technical or engineering reason why an IXP
actually needs IPv4 to facilitate IPv4 traffic exchange.
So instead of shrinking prefixes now and extending the life of the pool with no
predictable benefit to the community, I favor continuing to allocate /24s to
IXPs until they run out and then encouraging future IXPs to either engage the
transfer market or deliver IPv4 NLRI over IPv6.
I personally don't like this way of thinking to thrown away resources
unnecessary if there is an option to conserve them. In fact I am a bit
tired of this history of "let IPv4 go and deploy IPv6". It sound very
beautiful to say but in practice we all need to re-learn to work with
the IPv4 that is left as we will depend on it easily for over a decade
(or two), therefore we must continue being responsible on how we manage
what is left in order to facilitate the continuous work towards IPv6
deployment everywhere.
Isn't already enough the amount if problems arising from the IPv4
exhaustion and will only worse with time ?
I am definitely not of the opinion that continuing to apply best
conservation practices to whatever IPv4 is left is a bad thing and that
will impact or delay IPv6 deployment in any way. Both things can work
well together.
Fernando
Owen
Fernando
On 25/11/2023 22:33, owen--- via ARIN-PPML wrote:
The problem I have with this line of thinking is that in reality, IXPs are the
place with the least need for an IPv4 prefix.
It’s dirt simple to pass along IPv4 NLRI over an IPv6 peering session these
days, even if you’re not doing IPv6 anywhere else in your network.
The only real consequence of this is to make IPv4 trace routes look a little
funky on the hop that traverses the exchange.
Yes, there’s a perceptual hurdle to this and there are those that view an IPv6
only IXP as undesirable compared to a dual-stack one, but at some point, we’re
going to just have to get over that.
I don’t support shrinking IPv4 delegations from RIRs below /24 and multiple
IXPs have argued against doing so.
The only possible gain to this policy is prolonging the perceived life of IPv4
which, IMHO, is a step away from good. (Note, it won’t prolong the actual life
of IPv4, just increase the amount of pain involved while it lasts).
Owen
On Nov 25, 2023, at 16:55, Martin Hannigan <[email protected]> wrote:
Went back to work on language that may have an impact. We seem to have dropped
three paragraphs from drafts that are in the current policy. I can't tell if
it's intentional but I'll assume it was. Doesn't appear clearly marked for
deletion unless I missed it. The original or the June edit was also not a
mirror of the RIPE proposal. ARIN can decide if anything needs to be fixed
documentation wise or if we could use the help of a red line for the below.
Didn't matter much anyhow.
The easiest way to extend the life of the micro allocation pool will be to
apply better justification standards. Right now, 26% of US IXPs don't meet the
minimum criteria for an initial /24 using the existing policy. Most of that
happened in the last few years and as Aaron Wendell discussed at the last
meeting.
Here's what I support
- Initial allocation of a /26 to a new IXP, and
- Include "CI" to keep it simple and consistent. No reason to single out IXPs
- A voluntary global routability requirement determined by applicant for CI
- Tightened utilization requirements for CI
- Removing the possibility of other RIR's asking ARIN for allocations (glitch?)
If the root or a TLD can't do it, what makes anyone think an IXP can?
I agree with my RIPE friends' comments regarding up front costs. It already costs $11,000
for a "free" IXP without a /24. Add a transfer /24 and it's $22,000 not
including opex, RIR fees, depreciation, etc. If it does cost a future IXP an additional
$11,000 for a /24 and it's not easily absorbed (lots of that happening today) they failed
and will not start up. Turning the knobs on network economics should go slow - as they
also acknowledged. And should als be applied to non-CI first. That seems like a faster
way to enable better transition.
On a last note. It would be nice to have a "style sheet" so we had consistency with defined terms
and language. Repeating "under this section" and other "time honored traditions" makes
policy hard to read when it doesn't have to be.
4.4 Micro-allocation
ARIN will make IPv4 micro-allocations to critical infrastructure (“CI”)
providers of the Internet, which includes Internet Exchange Points (“IXP”),
IANA authorized root servers, top-level domain operators and this RIR. Requests
for IPv4 allocations will be no smaller than a /26 or larger than a /23 for
allocations which require global reachability. Global reachability requirements
will be determined by the requestor. ARIN will maintain a previously reserved
/15 of IPv4 address space for the purposes of CI allocations.
4.4.1 Additional Requirement for IXPs
An IXP requesting an initial IPv4 allocation from the blocks specifically
reserved for this purpose will initially be assigned a /26 allocated from a /24
by default if they demonstrate three independent ASN’s are planning to
interconnect on the IXP fabric using the requested allocation. An IXP
requesting an allocation larger than a /24 must show their plan to utilize more
than 50% of the requested allocation size up to a /23. Allocations larger than
a /23 will be considered on a case-by-case basis using usual and customary
allocation practices in effect at the time of the request.
On Tue, Nov 21, 2023 at 12:34 PM ARIN <[email protected]> wrote:
In accordance with the Policy Development Process (PDP), the
Advisory Council met on 16 November 2023.
The AC has advanced the following to Draft Policy status (will be
posted separately for discussion):
* ARIN-prop-327: Reduce 4.18 maximum allocation
The AC advances Proposals to Draft Policy status once they are
found to be within the scope of the Policy Development Process
(PDP) and contain a clear problem statement.
The AC has advanced the following to Recommended Draft Policy
status (will be posted separately for discussion):
* ARIN-2023-1: Retire 4.2.1.4. Slow Start
The AC advances Draft Policies to Recommended Draft Policy status
once they have been fully developed and meet ARIN's Principles of
Internet Number Resource Policy. Specifically, these principles are:
* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community
The AC is continuing to work on:
Draft Policies:
* ARIN-2022-12: Direct Assignment Language Update
* ARIN-2023-2: /26 initial IPv4 allocation for IXPs
* ARIN-2023-4: Modernization of Registration Requirements
* ARIN-2023-6: ARIN Waitlist Qualification
* ARIN-2023-7: Clarification of NRPM Sections 4.5 and 6.11
Multiple Discrete Networks and the addition of new Section 2.18
Organizational Identifier (Org ID)
Recommended Draft Policies:
* ARIN-2023-5: Clean-up of NRPM Sections 4.3.4, 4.4, 4.10 and 6.10.1
The PDP can be found at:
https://www.arin.net/participate/policy/pdp/
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/participate/policy/drafts/
Regards,
Eddie Diego
Policy Analyst
American Registry for Internet Numbers (ARIN)
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
