Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size
On 1/28/14, 20:48 , (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) wrote: Hi Owen, I'm sorry but I misread your commmet. | If you're going to do this, I would rather see providers given the option of choosing a size | ranging from /28 to /32 with encouragement towards either end (/28 or /32). As Guangliang wrote in his mail, only /29 is reserved for organizations in earlyer allcation address block. Main purpose of this policy intend to utilize those address, which will be kept unused. I'm confused, you seem to be saying you are suggesting /29 only because of the previous reservation in the older allocation process? I would recommend figuring out what the right thing is based on the current allocation processes and then figure out any adjustments needed to account for allocations made in the older processes. Rather than encoding an artifact of the older allocation processes into current policy, which is what this seems to be doing. Also, correct me if I'm mistaken, but by raising the default from /32 to /29, you are raising the barrier to entry for small LIRs. I believe APNIC's fees are based on your allocation size. Yes, its a logarithmic function, but it still raises the fees. So a small LIR that doesn't currently need a /29 may prefer to stick with a /32 for the lower fees. This policy seems to force all new allocations to /29, regardless of what an LIR needs or wants. Minimally, this change should be optional, allowing an LIR request range a larger range, but not requiring a larger range. Thanks. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On Feb 27, 2015, at 00:22, Dean Pemberton d...@internetnz.net.nz wrote: I'm sure Skeeve also thinks that organisations should be able to get all the IP addresses they might ever need all on day one. I'm sure he even knows a company who could arrange that for them. Well our IPv4 policies are explicitly designed to not provide all the IPv4 addresses an organization needs. Where as with IPv6 that is at least possible, maybe not forever, but there is a goal of 5 to 10 years or more for an initial allocation. Lets see where the community thinks this should go. It still sounds like unlimited ASNs for anyone who thinks they might like to have them. Great business for anyone clipping the ticket on the transaction. Now that we that have 4 billion ASNs, maybe we should reexamine our policy goals for ASNs, at least compared to when we only had 65 thousand ASNs. If we are willing to give an organization a routing slot with IPv4 or IPv6 PA or PI address block, why wouldn't we be willing to give them a ASN too? I would want them to provide additional justification why they need a second ASN, but the mere fact we gave then a PA or PI address block is probably sufficient justification for their first ASN. The reverse is also probably also true, if we are NOT willing to give them a routing slot, we probably should NOT be willing to give them an ASN either, at least without additional justification like multi-homing. -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. -- === David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 === * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On 2/27/15 17:41 , Dean Pemberton wrote: On Sat, Feb 28, 2015 at 8:03 AM, David Farmer far...@umn.edu wrote: Don't allocated one if they don't want one. But if they want one, and they already have PI, or getting new PI, then why say no? And its not regardless of need, more accurately in anticipation of future need. Nope - you almost had me, but now you've lost me again, well done. Sorry, let me try one more time. What you are suggesting *IS* regardless of need, and thats what I think people are missing. If you are not required to demonstrate need to get something, then it is allocated regardless of need. I realise this might seem semantic, but policy is all about semantics. On this we agree. This 'anticipation of future need' stuff is at best ethereal and at worst a fallacy. Lets not forget that there is an almost zero barrier to entry with regard to ASN allocation should the member require one. I just don't subscribe to this I may one day require one so give it to me now If you only look at it through the lens of the current multi-homing requirement for an ASN then you don't need it, it is totally anticipatory and only a future need, but that is self-fulfilling. I'm suggesting that multi-homing is too narrow of a definition of need for an ASN. The PI assignment and what every justified that should also equally justify the need for ASN assignment. The PI assignment was intended to be portable, also assigning an ASN simply is intended to facilitate that portability. I'm saying that the need for portability is also a need for an ASN, if you look beyond multi-homing. It's the same as saying I don't require an IPv6 allocation today, but I anticipate that at some point I'll need a /10. Just give it all to me now so that I don't have to make difficult design decisions later. If everyone gets one then I can live with that. What I can't live with is opening up a can of worms with a I might one day need something so please allocate it now. It's a dangerous slippery slope.Today ASNs, Tomorrow IPv4, next day IPv6. It's not that I only might need it, in my opinion it is fundamentally necessary to fulfill the portability of the PI assignment. No need to move the assignment within the routing system, no need for portability and no need for an ASN. But, if you make a PI assignment without allowing me an ASN you've limited its portability and the useability for its intended purpose. Making a PI assignment implies to me, it can be picked up and moved within the routing system, assigning an ASN is needed to facilitate that movement. However, looked at through the lens of multi-homing, portability itself is only a future need. You have to look beyond multi-homing, not abandon the idea of need, to understand what I'm trying say. But, I probably only dug the whole deeper. :) So, I'll stop now. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On 2/25/15 15:44 , Dean Pemberton wrote: ... There is essentially no barrier to entry here. If a site needs an ASN they are able to receive one. If they want one 'just in case', then that is against current policy and I'm ok with that. Dean From a policy perspective there is no barrier to entry. However, from an operational perspective, I see it a little differently; having deployed my network using a private ASN, I then need to migrate to a new unique registry assigned ASN. Which you are saying I can't have until I've grown to the point were I need to multi-home or connect to an IX. If I'm a small network, this may not be a big hardship. But if you connect to a single provider in multiple cities you could build a fairly extensive network that would not qualify for a registry assigned ASN until you got a second provider or connected to an IX, at which point the transition to the new ASN could be rather complicated. I'm not sure that justifies obliterating the current policy, but there is at least an operational barrier to entry in some situations. I think maybe a compromise would be to allow a network of a certain size to obtain an ASN regardless of having a unique routing policy, being multi-homed, or connected to an IX. A network of 1 or 2 routers probably doesn't justify an ASN unless it is multi-homed or connected to an IX. A network of 100 routers probably justifies an ASN regardless. Then the question becomes, where to draw the line. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] prop-132-v002: AS0 for Bogons
s a good idea to have measures in place to avoid any > erroneous triggers and thats why I said APNIC can put operational practices > in place for that. Its shouldn't be part of the policy. > > > I never advocated for making it part of the policy. I advocated for > reviewing it as part of the considerations BEFORE consenting to > implementation of the policy. > > I never asked for a change to the policy text. I asked for APNIC to > publish their anticipated operational procedures for review so that the > community can consider them in determining whether or not to come to > consensus on this policy proposal. > > In other words, I agree they shouldn’t be part of the policy, but they > MUST be part of the policy deliberation, IMHO. > > Also it’s seems you are fine with people advertising bogons just because >> fixing it might make one/two people unhappy. >> >> >> I’m not necessarily fine with people advertising bogons, but I’m also not >> necessarily convinced that I want the RIRs to become the routing police. >> >> This proposal literally moves the routing police role from the hands of >> those who run routers into the hands of the RIRs (well, specifically it >> moves part of that role in one region into the hands of one RIR). >> > > This policy is not doing anything special and giving extra powers to RIR. > It happened when we (the community) agreed to move forward with RPKI. Any > consequences you are relating to AS0 are also true for any other ROA. > Whether its a good thing or bad, we can all have different opinion but its > a reality. > > > If you believe that first sentence, then you really don’t understand the > current operational state of the internet. > > While you are correct about other ROAs, those other ROAs are not > originated by RIRs and cannot come into existence as a result of > disagreement between an ISP and an RIR (e.g. a billing dispute with an RIR). > > This does, in fact, substantially expand the power of the RIR to impact > ROAs. That is reality. > > I haven’t decided whether that’s a good ting or bad, but it’s definitely a > question that the community should carefully consider in evaluating this > policy. > > I’m not saying the potential outcomes are necessarily bad, but whatever > they may be, I want to maximize the probability that they are intended > rather than unintended consequences. > > Owen > > > * 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 -- === David Farmer Email:far...@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SEPhone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 === * 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
Re: [sig-policy] prop-132-v002: AS0 for Bogons
On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui wrote: > Hi David, > > > On Fri, Aug 23, 2019 at 6:36 AM David Farmer wrote: > >> The problem statement says; >> >> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet >> with an IP source address in an address block not yet allocated by IANA >> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and >> LACNIC)... >> >> >> So that raises a question, what about resources that are deregisterd >> because they are returned, revoked, or otherwise reclaimed, for any of a >> myriad of reasons, including non-payment of fees? Do they become Bogons >> with AS0 ROAs the moment they are deregistered? Later, if so when? What if >> there is a ROA for them in the system? Are the ROAs removed, if so when? >> > > I also had some concerns about revoked and/or reclaimed space and closed > account due to non payment so I asked Secretariat in advance and here is > the response. > === > APNIC membership account is classified as closed when its status is > flagged as ‘closed’ in APNIC’s internal system. > > 30 days - payment period upon issuance of invoice, if no payment is > received within this period member receives expiry notice and the account > status becomes 'suspended' > After 15 days – member receives email notification for closure giving them > another 15 days to pay > After 15 days – the status of the account becomes 'closed' and all > delegated resources under the account are reclaimed > > All in all members have 60 days period to pay before the status of the > account becomes ‘closed’. > === > > As long as the account is suspended APNIC doesn't consider those resources > as free/available/reclaimed and because they are not part of unallocated > pool thats why no need to create AS0 ROAs for such resources. AS0 ROAs will > be created once APNIC mark those resources available and remove them from > their delegation record. Now, the second issue is if there is a ROA for > them in the system. Because AS 0 ROA has a lower relative preference than > any other ROA that has a routable AS then APNIC has to somehow delete the > existing ROA from the system. Its easy if the member account is closed and > all resources are reclaimed. But I leave this to APNIC to decide how they > are going to make that happen. > Currently, when the account is closed nothing actively makes the resources unusable, accept for if you were also changing providers during this timeframe, then when the new provider checks the resources they will be unregistered. But most providers don't recheck the registration of resources very often, if ever, other than at the time of setup of service. With this proposal at some point, the resource will effectively become unusable with nonpayment, when the AS0 ROA is created, and any ROAs are removed, I'm fine with this, but it should be called out as a consequence of the proposal, so no one can say they didn't realize that is a consequence of the proposal. This proposal changes the consequences for nonpayment, that should be made clear in the proposal one way or another. Also as Owen noted the RIRs frequently have a hold period after the account is closed, resource are usually held for some period after account closure and before they are reissued to a new user. > Personally I think they should be deregistered for some amount of time >> before the becoming Bogons and have an AS0 ROA created them, also for the >> AS0 ROA to be effective any ROAs for these deregistered resources need to >> be removed as well. >> > >> I would propose something like the following; >> >>1. Upon de-reregistration any existing ROAs are removed from RPKI >>2. 30 days after de-registraion, AS0 ROAs are created except for >>non-payment fees >>3. 90 days after de-registraion, AS0 ROAs are created in the case of >>non-payment fees >> >> Thanks. >> > > Thanks for these suggestions but do you think the existing waiting period > as outlined above in APNIC's response is good enough to mark them as > free/unallocated? or you think additional cooling-off window should be > added after the account is closed? How about 30 days after de-registration > whether it was closed due to non-payment or otherwise. > They were just suggestions, but I will note that you only discussed the timing for nonpayment, resources can be returned voluntarily or they can be revoked for cause, this is rare but it does happen and the timing assoicated with these instances should be understood as well. Also, I was suggesting the AS0 ROAs should not created immediately on account closure but some period of time after that, Right now there
Re: [sig-policy] prop-132-v002: AS0 for Bogons
> and only APNIC can issue AS0 (zero) ROAs. Once they ROA is issued and > APNIC wants to allocate > the address space to its member, simply they can revoke the ROA and > delegate the address space > to members. (this proposal doesn't formulate operational process). > > 5. Advantages / Disadvantages > - > Advantages: > Those implementing ROV globally and discarding the invalids will be able > to discard bogons from > APNIC region automatically. > > Disadvantages: > No apparent disadvantage > > 6. Impact on resource holders > - > No impact to APNIC or respective NIR resource holders not implementing > ROV. Those implementing ROV > and discarding the invalids will not see any bogons in their routing table. > > > 7. References > --- > RFC6483 - https://tools.ietf.org/rfc/rfc6483.txt > RFC6491 - https://tools.ietf.org/rfc/rfc6491.txt > RFC7607 - https://tools.ietf.org/rfc/rfc7607.txt > ___ > * 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 -- === David Farmer Email:far...@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SEPhone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 === * 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
[sig-policy] Re: New proposal: prop-158-v001: IPv6 auto-allocation for each IPv4 request
On Wed, Jan 24, 2024 at 9:49 PM Fernando Frediani wrote: > > On Wed, 24 Jan 2024, 21:50 Christopher Hawker, > wrote: > >> NIRs may well continue to exist and perform their administrative >> functions under the umbrella of the RIR facilitating things in certain >> economies and cultures. >> >> NIRs are independent of RIRs and operate via a NIR Member Relationship >> Agreement. The MRA outlines what NIRs are able to do. >> > > That is a problem on this discussion, a big missundertanding about how > things are organized in practice. > I think you are arguing about semantics; I believe APNIC gives NIRs significant latitude to create local policies and procedures appropriate to their local economies, culture, or laws; Nevertheless, the "APNIC and NIR Member Relationship Agreement" clearly states, "Recitals; c. ... National Internet Registries provide procedures and services that take account of local cultural differences, while operating in a way that remains consistent with regional and global resource management policies." Further, "2.3 Termination, a. APNIC may terminate this agreement in any of the following circumstances: 4. The NIR Member commits a substantial breach of this agreement or any APNIC Address Management Policy;" https://www.apnic.net/about-apnic/corporate-documents/documents/membership/nir-membership-agreement/ https://www.apnic.net/community/policy/operational-policies-nirs/ "APNIC and NIR Member Relationship Agreement" is a cooperative agreement or contract. It, therefore, doesn't override local or international laws, and the only real enforcement action is the termination of the agreement. Furthermore, I imagine APNIC would not pursue termination of the agreement except under the most egregious violation and only after both informal and formal opportunities to correct the situation. Can we please get back to the policy discussion at hand? Thanks. -- === David Farmer Email:far...@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SEPhone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 === ___ SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an email to sig-policy-le...@lists.apnic.net
[sig-policy] Re: New proposal: prop-158-v001: IPv6 auto-allocation for each IPv4 request
I do not believe this policy will achieve its stated objective: to accelerate IPv6 implementation. Automatically delegating IPv6 address space to new and initial IPv4 requests, may increase the number of IPv6 delegations. But, the bar to get an IPv6 delegation is already pretty low, and it is not the limiting factor for IPv6 implementation in a network. The limiting factor is the actual work of implementing IPv6 in a network. I suspect many, if not most, networks requesting IPv4 will accept the IPv6 delegation and simply fail to proceed with its IPv6 implementation in their network. IPv4 policy has not been and will not be an effective lever to increase IPv6 implementations. Thanks. -- === David Farmer Email:far...@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SEPhone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 === ___ SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an email to sig-policy-le...@lists.apnic.net
