> On Jul 21, 2023, at 13:54, Noah <[email protected]> wrote:
> 
> 
> 
> On Fri, 21 Jul 2023, 21:07 Delong.com via SIG-policy, 
> <[email protected] <mailto:[email protected]>> wrote:
>> Must we continue to rearrange the deck chairs?
> 
> 
> I see a lot of rational for the chairs moves...

I see more time wasted diddling with an obsolete and dying protocol instead of 
focusing on moving forward.

> 
>> 
>> Let it sink already… IPv6 will float.
> 
> 
> While wish for it to sink... its whats holding the INET together...

No, it’s what’s ripping the INET apart. It’s why most internet users are 
relegated to second class citizenry behind NAT. It’s why applications are built 
with bogus assumptions about the nature of addressing:
        Philips assumes that all members of a household share a common public 
IP address.
                This is annoying in a household that isn’t behind a single NAT.
        Philips also assumes that all things behind a single public IP address 
are a single household.
                This is not only annoying, but it’s a serious security risk to 
any household behind CGN.
        Lots of applications assume that you can’t directly talk back to your 
device in your home and
                that you have to work through some sort of phone-home 
intermediary system. This
                creates unnecessary overhead and barriers to making certain 
things work in any
                environment that doesn’t have these limitations.

> v6 will float but spontenously for the next 30 years...

Yes, v6 will float spontaneously (which is the word I think you were looking 
for).
Yes, I expect v6 will last at least the next 30 years.
OTOH, while v4 will likely still be hanging around (like an anchor on our 
necks), I suspect it will be islands of v4 on internal networks and not remain 
the lingua franca of the internet for more than a few more years.

All this proposal accomplishes is to preserve the illusion of IPv4 address 
availability at the expense of current need.

Basically, like most austerity policies around IPv4, it punishes the existing 
users for the sake of imaginary future users.

Owen

> 
> Noah
> 
>> 
>> Owen
>> 
>> 
>>> On Jul 20, 2023, at 22:13, Shaila Sharmin <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> Dear SIG members,
>>> 
>>> A new proposal "prop-152: Reduce the IPv4 delegation from /23 to /24"
>>> has been sent to the Policy SIG for review.
>>> 
>>> It will be presented at the Open Policy Meeting (OPM) at APNIC 56 on
>>> Thursday, 14 September 2023.
>>> 
>>>      https://conference.apnic.net/56/program/program/#/day/8/
>>> 
>>> We invite you to review and comment on the proposal on the mailing list
>>> before the OPM.
>>> 
>>> The comment period on the mailing list before the OPM is an important
>>> part of the Policy Development Process (PDP). We encourage you to
>>> express your views on the proposal:
>>> 
>>>    - Do you support or oppose this proposal?
>>>    - Does this proposal solve a problem you are experiencing? If so,
>>>      tell the community about your situation.
>>>    - Do you see any disadvantages in this proposal?
>>>    - Is there anything in the proposal that is not clear?
>>>    - What changes could be made to this proposal to make it more effective?
>>> 
>>> Information about this proposal is appended below as well as available at:
>>> 
>>>      http://www.apnic.net/policy/proposals/prop-152
>>> 
>>> Regards,
>>> Bertrand, Shaila, and Anupam
>>> APNIC Policy SIG Chairs
>>> 
>>> 
>>> ---------------------------------------------------------------
>>> 
>>> prop-152-v001: Reduce the IPv4 delegation from /23 to /24
>>> 
>>> ----------------------------------------------------------------
>>> 
>>> Proposer: Rajesh Chharia ([email protected] <mailto:[email protected]>) and 
>>> Vivek Narayan
>>> ([email protected] <mailto:[email protected]>)
>>> 
>>> 
>>> 1. Problem statement
>>> --------------------
>>> APNIC's available IPv4 addresses in the final 103/8 are down to 0.3%,
>>> and APNIC will soon begin
>>> delegating from the recovered and/or reserved address space.
>>> 
>>> Delegated: 887,431,680 (99.5%)
>>> Available: 2,792,192 (0.3%)
>>> Reserved:  1,293,568 (0.1%)
>>> 
>>> Note: ‘Reserved’, as defined by APNIC, means the resource has not been
>>> allocated or assigned to
>>> any entity and is not available for allocation or assignment. This may
>>> include reserved space as
>>> defined in the policy document or by the IETF, voluntarily returned
>>> space that is undergoing
>>> quality checks, or reclaimed space awaiting administrative clearance.
>>> 
>>> 
>>> 2. Objective of policy change
>>> -----------------------------
>>> The current final /8 allocation policy[1] requires that the current
>>> minimum delegation size for
>>> IPv4 is a /24 and each APNIC account holder is only eligible to receive
>>> IPv4 address delegations
>>> totalling a maximum /23 from the APNIC 103/8 IPv4 address pool.
>>> 
>>> As stated above, the available APNIC 103/8 IPv4 address pool for APNIC
>>> account holders is shrinking.
>>> 
>>> At the rate of current delegation size, it is expected that this pool
>>> will be depleted in 2024.
>>> 
>>> To further accelerate Internet growth in the Asia Pacific region, it is
>>> recommended that some
>>> IPv4 address space be made available in the APNIC service region for new
>>> businesses, startups,
>>> and so on, so that they can prepare for IPv6 migration rather than
>>> purchasing market transfers,
>>> which may be prohibitively expensive for new entrants.
>>> 
>>> Account holders who have already received IPv4 addresses will be
>>> motivated to implement IPv6.
>>> 
>>> 
>>> 3. Situation in other regions
>>> -----------------------------
>>> There is no similar policy in place in other RIR regions.
>>> 
>>> 
>>> 4. Proposed policy solution
>>> ---------------------------
>>> 1. No change to the current policy[1] to current minimum delegation size
>>> for IPv4 is a /24 and
>>> each APNIC account holder is only eligible to receive IPv4 address
>>> delegations totalling a
>>> maximum /23 from the APNIC 103/8 IPv4 address pool. APNIC can continue
>>> with this policy until
>>> all of the available 2,792,192 (0.3%) resources are depleted.
>>> 
>>> 2. Once the available 2,792,192 (0.3%) resources are depleted, APNIC and
>>> NIR account holders
>>> who already received IPv4 address space cannot receive any further IPv4
>>> addresses.
>>> 
>>> 3. APNIC and NIRs will delegate a maximum of /24 IPv4 addresses to their
>>> new account holders,
>>> with no IPv4 addresses, from  the current 'Reserved' pool and any
>>> subsequent reserved pool in
>>> the future which will be made available for delegation.
>>> 
>>> 4. If APNIC runs out of all of IPv4 addresses, a waiting list for new
>>> requestors with no IPv4
>>> addresses must be created on a first come, first served basis.
>>> 
>>> 
>>> 5. Advantages / Disadvantages
>>> -----------------------------
>>> Advantages:
>>> This proposal allows new businesses, startups, and so on to access the
>>> IPv4 resources in the APNIC region.
>>> This proposal also can help in the uptake of IPv6 deployments in the
>>> APNIC region.
>>> 
>>> Disadvantages:
>>> No disadvantages are foreseen.
>>> 
>>> 
>>> 6. Impact on resource holders
>>> -----------------------------
>>> This will affect NIR members in the same way as APNIC members.
>>> 
>>> 
>>> 7. References
>>> -------------
>>> [1] Section 6.1. "Minimum and maximum IPv4 delegations" of "Policies for
>>> IPv4 address
>>> space management in the Asia Pacific region"
>>> 
>>> https://www.apnic.net/community/policy/resources#a_h_part_2
>>> 
>>> 
>>> _______________________________________________
>>> SIG-policy - https://mailman.apnic.net/[email protected]/
>>> To unsubscribe send an email to [email protected] 
>>> <mailto:[email protected]>
>> _______________________________________________
>> SIG-policy - https://mailman.apnic.net/[email protected]/
>> To unsubscribe send an email to [email protected] 
>> <mailto:[email protected]>
_______________________________________________
SIG-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]

Reply via email to