Re: [sig-policy] New Proposal prop-141-v001: Change maximum delegation size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses
Satoru San and JPOPF Team, Thanks for your valuable comment on the Policy Proposal. We will try to update our proposal according to your comments and advice. - with regards SIMON. On Wed, Sep 1, 2021 at 2:52 PM Tsurumaki, Satoru wrote: > Dear Colleagues, > > I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.. > > I would like to share key feedback in our community for prop-141, > based on a meeting we organised on 25th Aug to discuss these proposals. > > Many neutral opinions were expressed about this proposal. > > (comment details) > - From a macroscopic perspective, IPv4 has already been exhausted, >so this proposal is not expected to have a significant impact. > - This is a proposal from a user's perspective by a proposer >who is in trouble, and we think it is a valuable proposal. >As the proposal includes measures to prevent complete exhaustion >ahead of schedule, we think the opinions of the proposer should be >respected. > - The number of routes will increase by 10,000, but this is small in >relation to the total number of routes, so it should not be a concern. > > > Regards, > > Satoru Tsurumaki / JPOPF Steering Team > > > 2021年8月30日(月) 21:39 Srinivas (Sunny) Chendi : > >> Dear all, >> >> Here is the Secretariat impact assessment for proposal "prop-141-v001: >> Change maximum >> delegation size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) >> addresses". >> >> APNIC notes the proposed delegation of additional /24 to the existing >> members, as per the >> criteria under Section 7.0 "Subsequent IPv4 delegations" who received a >> maximum of /23 >> (under current policy) after Thursday, 28 February 2019, and the >> proposed new >> policy to change the IPv4 maximum delegation size to a /23 +/24 to the >> new members. >> >> APNIC also notes the following proposed thresholds: >> - IPv4 maximum delegation size will automatically changes to a /23 if >> the available (incl reserved) IPv4 pool comes down to 900k. >> - IPv4 maximum delegation size will automatically changes to a /24 if >> the available (incl reserved) IPv4 pool comes down to 256k, and >> add the /16 reserved for future use to the available pool. >> >> This proposal would require changes to the website content, procedure >> documents and manuals, training material, membership >> forms and various registry systems. >> >> If this proposal reaches consensus, implementation may be completed >> within 3-6 months. >> >> Clarifications required: >> 1. When the available IPv4 pool is down to 900k or 256k, and in case if >> a large IPv4 address space is added to this available pool, >> will the maximum delegation size automatically revert to /23+/24 or /23, >> or not? >> >> Regards, >> Sunny >> >> On 13/08/2021 10:00 am, Bertrand Cherrier wrote: >> > Dear SIG members, >> > >> > The proposal "prop-141-v001: Change maximum delegation size of IPv4 >> > address from 512 ( /23 ) to 768 (/23+/24) addresses" has been sent >> > to the Policy SIG for review. >> > >> > It will be presented at the Open Policy Meeting (OPM) at APNIC 52 >> > on Thursday, 16 September 2021. >> > >> > >> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconference.apnic.net%2F52%2Fprogram%2Fschedule%2F%23%2Fday%2F4data=04%7C01%7C%7C0c88d9ff2a3e4b77366608d95ded6d87%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637644097784605051%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=RgeAtrf1ze9SiEEHqSpVoB1dZJ4mv8O0oygInlB%2Bt7Y%3Dreserved=0 >> > >> > >> > 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 and also available at: >> > >> > >> https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apnic.net%2Fpolicy%2Fproposals%2Fprop-141data=04%7C01%7C%7C0c88d9ff2a3e4b77366608d95ded6d87%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637644097784605051%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=alrD0MZrJcV9sfP3%2FEs3zy1Ynz8YBXx4zEQHsLQcZGs%3Dreserved=0 >> > >> > >> > Regards, >> > Bertrand and Ching-Heng >> > APNIC Policy SIG Chairs >> > >> > >> > --- >> > >> > prop-141-v001: Change maximum delegation size of IPv4 address from 512 >> > ( /23 ) to 768 (/23+/24) addresses >> > >> >
Re: [sig-policy] Reminder: Join the APNIC Policy Development Process Community Consultation
Hi SIG Chairs, Thanks for Arranging Such wonderful and interactive Community Consultation Virtual Event. After this meeting I have found that it is always easy and understandable when we hear any policy/proposal/editorial-changes with detail description and background story, as Sunny did today. As in APAC, most of our mother language is not English. In future when the Policy Proposer will submit a new policy, we want to see the same kind of Virtual consultation/policy read-out before the APNIC Conference takes place. With this, the Policy Proposer can get the comment/feedback from the community before they present at the conference and we (the community) can easily understand the policy in detail. Again an excellent job by Sunny and the whole team. Regards SIMON. On Thu, Oct 29, 2020 at 6:50 AM Srinivas (Sunny) Chendi wrote: > This is a reminder to join the APNIC Policy Development Process > Community Consultation as invited by the Policy SIG Chairs. Today is the > deadline for registration. > > The consultation session is free and open to anyone who wishes to > participate. > > If you are interested, please register here > > > https://www.apnic.net/community/participate/sigs/community-consultation/ > > Kind Regards, > Sunny > APNIC Secretariat > > > > On 26/10/2020 8:48 am, Bertrand Cherrier wrote: > > Dear Colleagues, > > > > Thank you for taking the time to join the Policy SIG Open Policy Meeting > > (OPM) at APNIC 50. > > > > With all policy discussions remaining online-only for the foreseeable > > future, we believe there is a need to provide additional opportunities > > for the community to discuss policy matters (in addition to the mailing > > list) ahead of APNIC 51. > > > > In particular, the Policy Development Process (PDP) review report > > contains important recommendations for community discussion. > > > > We invite you to join a virtual community consultation session on this > > topic: > > > > Session Date: Friday, 30 October 2020 > > Session Time: 11:00 (UTC+8) (Time converter > > > https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fy5xjej2ddata=04%7C01%7C%7C00e164cc9c024bc8d1bb08d8793824d8%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637392630391306336%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=h8KyuUQYtvqjzf5qwoduP0tIu1kWqfqusPYJrMwNLI0%3Dreserved=0) > > > > > Duration: 1 hour > > > > The consultation session is free and open to anyone who wishes to > > participate. If you are interested, please register here by Thursday, 29 > > October 2020. > > > > > > > https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apnic.net%2Fcommunity%2Fparticipate%2Fsigs%2Fcommunity-consultation%2Fdata=04%7C01%7C%7C00e164cc9c024bc8d1bb08d8793824d8%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637392630391306336%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=T1xIRSB2ly%2BAty0IGK6yBeOtZMqc%2BmuflKz6NjJFgrU%3Dreserved=0 > > > > > > After registering, you will receive a confirmation email containing > > information about joining the meeting. > > > > Useful links for reference: > > > > - PDP and SIG Guidelines Review Report > > > > > https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconference.apnic.net%2F50%2Fassets%2Ffiles%2FAPCS790%2FPDP-and-SIG-Guidelines-Review-Report%2520.pdfdata=04%7C01%7C%7C00e164cc9c024bc8d1bb08d8793824d8%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637392630391306336%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=sFVPnd%2FQlZhnkMzJi5XpCYRmus1gopHgFmam70m%2BvbM%3Dreserved=0 > > > > > > - Policy Development Process (PDP) redline document > > > https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fftp.apnic.net%2Fapnic%2Fdrafts%2Fpdp-v002-v003-diff.htmldata=04%7C01%7C%7C00e164cc9c024bc8d1bb08d8793824d8%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637392630391306336%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=oB8m2sEQrHxtNYp0YTvtzbCxwb0N4F4uoZTGd430yU4%3Dreserved=0 > > > > > > We look forward to engaging with you online. > > > > Have a nice day, > > > > Regards, > > > > Bertrand and Ching-Heng > > APNIC Policy SIG Chairs > > > * sig-policy: APNIC SIG on resource management policy >* > ___ > sig-policy mailing list > sig-policy@lists.apnic.net > https://mailman.apnic.net/mailman/listinfo/sig-policy -- *Simon Sohel Baroi *| DGM | International Gateway and Cable | Cell : +880-181-7022207 | Desk : +880-9666776677 Ext-1702 | Mail : simon.ba...@fiberathome.net | Skype : tx.fttx | * Reduce. Reuse. Recycle. Respect. It's the little things that really can make a difference. * * sig-policy: APNIC SIG on resource management policy *
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
Dear Sir, Also, Requesting to the Author to represent the Proposal with Example and Graphical Representation. The example should have comparison with Present situation and the Propose Solution of the problem. - with regards SIMON. On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir wrote: > Dear SIG members > > A new version of the proposal "prop-124: Clarification on Sub-Assignments" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > Information about earlier versions is available from: > https://www.apnic.net/community/policy/proposals/prop-124 > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Please find the text of the proposal below. > > Kind Regards, > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-124-v006: Clarification on Sub-Assignments > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > Note that this proposal is ONLY relevant when end-users obtain direct > assignments > from APNIC, or when a LIR obtains, also from APNIC, and assignment for > exclusive > use within its infrastructure. Consequently this is NOT relevant in case > of LIR > allocations. > > When the policy was drafted, the concept of assignments/sub-assignments > did not > consider a practice very common in IPv4 which is replicated and even > amplified > in IPv6: the use of IP addresses for point-to-point links or VPNs. > > In IPv4, typically, this is not a problem if NAT is being used, because > the assigned > addresses are only for the WAN link, which is part of the infrastructure > or interconnection. > > In the case of IPv6, instead of unique addresses, the use of unique > prefixes > (/64) is increasingly common. > > Likewise, the policy failed to consider the use of IP addresses in > hotspots hotspots > (when is not an ISP, for example, associations or community networks), > or the use of > IP addresses by guests or employees in Bring Your Own Device (BYOD) and > many other > similar cases. > > One more case is when an end-user contracts a third-party to do some > services in their > own network and they need to deploy their own devices, even servers, > network equipment, > etc. For example, security surveillance services may require that the > contractor provides > their own cameras, recording system, even their own firewall and/or > router for a dedicated > VPN, etc. Of course, in many cases, this surveillance system may need to > use the addressing > space of the end-user. > > Finally, the IETF has recently approved the use of a unique /64 prefix > per interface/host > (RFC8273) instead of a unique address. This, for example, allows users > to connect to a hotspot, > receive a /64 such that they are “isolated” from other users (for > reasons of security, > regulatory requirements, etc.) and they can also use multiple virtual > machines on their > devices with a unique address for each one (within the same /64). > > > 2. Objective of policy change > - > > Section 2.2.3. (Definitions/Assigned Address Space), explicitly > prohibits such assignments, > stating that “Assigned ... may not be sub-assigned”. > > It also clarifies that the usage of sub-assignments in ISPs, data > centers and similar cases > is not allowed, according to the existing practices of APNIC. > > > 3. Situation in other regions > - > > This situation, has already been corrected in AFRINIC, ARIN, LACNIC and > RIPE. > > > 4. Proposed policy solution > --- > > Current Text > 2.2.3. Assigned address space > Assigned address space is address space that is delegated to an LIR, or > end-user, > for specific use within the Internet infrastructure they operate. > Assignments must > only be made for specific, documented purposes and may not be sub-assigned. > > > New text: > 2.2.3. Assigned address space > Assigned address space is address space that is delegated to an LIR, or > end-user, > for exclusive use within the infrastructure they operate, as well as for > interconnection > purposes. > > The assigned address space must only be used by the original recipient > of the assignment, > as well as for third party devices provided they are operating within > said infrastructure. > > Therefore, sub-assignments to third parties outside said infrastructure > (for example > using sub-assignments for ISP customers), and providing addressing space > to third > parties in data-centers (or similar cases), are not allowed. > > > 5.
Re: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy
Dear Sir, Requesting to the Author to represent the Proposal with Example and Graphical Representation. The example should have comparison with Present situation and the Propose Solution of the problem. - with regards SIMON. On Fri, Aug 9, 2019 at 3:59 PM Sumon Ahmed Sabir wrote: > > Dear SIG members, > > The proposal "prop-131-v001: Editorial changes in IPv6 Policy" has been > sent to > the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. 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 available at: > http://www.apnic.net/policy/proposals/prop-131 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-131-v001: Editorial changes in IPv6 Policy > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > This proposal suggests multiple (mainly) editorial changes in the IPv6 > Policy. > The intent is to remove non-necessary text, and simplify the policy. > > Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is > removed, > as it is something obvious that operators need to assign some space for > different > parts of their own infrastructure. > > Section 5.2.4.3. explicitly states that it was drafted at a time when > there was no > experience with IPv6 deployment, which is this is longer the case, it > does not make > sense to have NIR/RIR to evaluate each instance where an LIR has an End > User whose > end site(s) requires a shorter prefix than a /48. > > Finally, section 10.1.4.1. is reworded, taking advantage of some of the > editorial > changes in the precedent sections, so to avoid duplicating text. > > > > 2. Objective of policy change > - > > Fulfil the above indicated edits. > > > 3. Situation in other regions > - > > A similar proposal has been submitted to RIPE. > > > 4. Proposed policy solution > --- > > Current Text > 5.2.4.2. Assignment address space size > > ... > > End-users are assigned an end site assignment from their LIR or ISP. The > exact size of > the assignment is a local decision for the LIR or ISP to make, using a > minimum value of > a /64 (when only one subnet is anticipated for the end site) up to the > normal maximum of > /48, except in cases of extra large end sites where a larger assignment > can be justified. > > ... > > > New Text > 5.2.4.2. Assignment address space size > > ... > > End Users are assigned an end site assignment from their LIR or ISP. The > size of the > assignment is a local decision for the LIR or ISP to make, using a value > of "n" x /64. > BCOP RIPE690 Section 4.2, provides guidelines about this. > > ... > > == > > Current Text > 5.2.4.3. Assignment of multiple /48s to a single end site > > When a single end site requires an additional /48 address block, it must > request the > assignment with documentation or materials that justify the request. > Requests for multiple > or additional /48s will be processed and reviewed (i.e., evaluation of > justification) at > the RIR/NIR level. > > Note: There is no experience at the present time with the assignment of > multiple /48s to > the same end site. Having the RIR review all such assignments is > intended to be a temporary > measure until some experience has been gained and some common policies > can be developed. > In addition, additional work at defining policies in this space will > likely be carried out > in the near future. > > > New Text > 5.2.4.3. Assignment of multiple /48s to a single end site > > Assignment larger than /48 (shorter prefix) or additional assignments > exceeding a total of > /48 must be made based on address usage, or because different routing > requirements exist > for additional assignments. > > In case of a review or when making a request for a subsequent > allocation, the LIR must > be able to present documentation justifying the need for assignments > shorter than a > /48 to a single End-Site. > > > > Current Text >
