Re: [sig-policy] prop-110v001: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
On 1/27/14, 12:20 , Leo Vegoda wrote:
David Conrad wrote:
On Jan 26, 2014, at 8:26 PM, Hannigan, Martin wrote:
That and isn't the IETF the right venue to carve out a specific from
a /8? This is in effect global policy, isn't it?
I suppose APNIC could throw it back to IANA (maybe? not sure how an
RIR can throw a /24 back to IANA -- perhaps that needs a global policy
too?)
I don't want to comment on which venue is appropriate. However, I can
report that we have some experience with this kind of thing based on
ARIN-prop-154, which ended up with RFC 6598. In that case, ARIN made a /10
available and we registered it in the IANA IPv4 Special-Purpose Address
Registry when the draft was approved. The implementation of things like
this is generally not a problem.
Regards,
Leo Vegoda
ICANN, IANA
Hello, from cold as {expletive deleted} Minnesota, were the low last
night was -17F (-27C) air temperature, with the wind chill near the
crossover point for Fahrenheit and Celsius at about -40.
When I first saw this policy last weekend, I was convinced it belonged
in the Special-Purpose Address Registry and MUST go through the IETF.
But, I decided not to comment until I had time to actually read the
proposal.
So, I've read the proposal, and I have to say I no longer think it
belongs in Special-Purpose Address Registry, at least not yet. The
proposal is for a non-exclusively registered block. 1.2.3.0/24 will
simply be registered to multiple entities. And, any unregistered use
would be technically invalid.
So, I have a few thoughts;
First, I want to confirm the issuance of a ROA for any and all use of
the 1.2.3.0/24 block is mandatory by the policy as proposed?
I think the policy should also require the full list of registered
authorized users be published along with the originating ASNs to be
used. My recommendation is that the APNIC database points to a web page
were all registered authorized users and their associated originating
ASNs are published.
I'd like to suggest this allocation be made with an experimental status
for now, without any time limit, but with predetermined review in two
years. I'm not sure anyone is really sure this will be good practice or
not. But, by designating this experimental, there is no connotation
that APNIC or anyone else is recommending this practice, at least at
this time. Further, it makes clear the APNIC community retains the
option to pull this back if it proves to be a stupendously bad idea.
so, in two years the community reviews the idea and may; continue the
experiment, make it production under the proposed multiple registration
process, propose a draft to the IETF and put it in the Special-Purpose
Address Registry, or pull the plug on the idea and officially notify all
registered users.
If the publication of the authorized users were clarified and its given
an experimental status I would, fully support this proposal.
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] 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] prop-110v001: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
Dean, I understand the cost issues involved. However, the RPKI ROAs and the registration of the non-exclusive users of the prefix is what distinguished this from a special-purpose allocation that needs IETF Review to be made. If you remove that part of the proposal then you should include how you intend to proceed on the issue of IETF Review, or clarify how this is not a special-purpose allocation that needs IETF Review. Here are a few references; http://tools.ietf.org/html/rfc2860 http://tools.ietf.org/html/rfc6890 http://www.iana.org/assignments/iana-ipv4-special-registry Thanks. On 2/4/14, 16:46 , Dean Pemberton wrote: Thank you for the reply. I can see how the process weight could vastly change the cost of implementation. To that end to co-authors have a proposed solution. Upon careful consideration of the underlying reasoning behind this proposal, the RPKI section may not be required. It does not make sense to attempt to protect this prefix from hijacking when by it's very nature it's available for non-exclusive use. We will remove the references RPKI and send an updated draft as soon as possible. Regards, Dean -- 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. On Wed, Feb 5, 2014 at 11:04 AM, Sanjaya Sanjaya wrote: Hi Dean and all, My apologies for the delayed reply. On the cost of extending the RPKI system to cover the need of this proposal, it really depends on the degree of automation desired in managing the registration of this particular block. A fully automated process will not cost much at all. Any manual oversight of the process will likely increase the cost significantly. Any idea how heavy/lightweight the registration process should be? Regards, Sanjaya Sanjaya, Gaurab has bought to light an important issue which is central to this proposal. Could I request information regarding the marginal cost of creation of an additional RPKI ROA to an existing allocation be made public to the list. I appreciate that exact figures may be difficult to obtain given the tight time constraints, to make this easier, an upper and lower bound on this cost would also be fine Once again, thanks for bringing up this issue Gaurab. Regards, 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. * 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 * 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 -- ======== 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-110v001: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
On 2/4/14, 17:44 , Randy Bush wrote: I understand the cost issues involved. However, the RPKI ROAs and the registration of the non-exclusive users of the prefix is what distinguished this from a special-purpose allocation that needs IETF Review to be made. If you remove that part of the proposal then you should include how you intend to proceed on the issue of IETF Review, or clarify how this is not a special-purpose allocation that needs IETF Review. always good to have folk from outside the region telling everyone what they SHOULD do. randy I did not intend the normative SHOULD that you are implying, if you prefer s/should/"MAY WISH TO" and see RFC 6919. http://tools.ietf.org/html/rfc6919 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] prop-109v001: Allocate 1.0.0.0/24 and 1.1.1.0/24 to APNIC Labs as Research Prefixes
On 1/25/14, 19:19 , Andy Linton wrote: Dear SIG members The proposal "prop-109v001: Allocate 1.0.0.0/24 <http://1.0.0.0/24> and 1.1.1.0/24 <http://1.1.1.0/24> to APNIC Labs as Research Prefixes" has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 37 in Petaling Jaya, Malaysia, on Thursday, 27 February 2014. 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? Seems sensible, support it, to the extent that matters as I don't represent any resources in the APNIC region. - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. Maybe, would the intent be to formally make these prefixes available to other researchers for general purpose Internet research? Or is the intent to only research the traffic phenomenons associated with 1.0.0.0/24 and 1.1.1.0/24. - Do you see any disadvantages in this proposal? If these prefixes start to become considered Bogon prefixes by operators and they start to be filtered, is there anything to research? - Is there anything in the proposal that is not clear? Should operators start filtering these Prefixes as Bogons or not? - What changes could be made to this proposal to make it more effective? More information about the long-term intent for these prefixes would be useful. The original stated intend was to monitor them to see if they could ever be used normally. The conclusion seems to be NO! Which I would tend to agree with. However, since we seem to be saying there is "no hope" for these prefixes, a natural reaction by some operators would be to filter them. Are we being asked to not filer them so they may be used for research? Some more specifics on the long-term intent might be helpful, especially if you don't want operators to just conclude they should filer these prefixes. 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 version of prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
On 2/13/14, 13:08 , Masato Yamanishi wrote: Dear SIG members A new version of the proposal "prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure" has been sent to the Policy SIG for review. Information about earlier versions is available from: http://www.apnic.net/policy/proposals/prop-110 You are encouraged to express your views on the proposal: - Do you support or oppose this proposal? I support the proposal, to the extent that matters as I don't represent any resources in the APNIC region. - Is there anything in the proposal that is not clear? The new version deals with several issues already discussed on the list. However, the text is now clear that this prefix is intended "for use in the context of locally scoped infrastructure". Therefore as a consequence, I think it would be helpful to clarify that it is acceptable to filter this prefix at an administrative boundary, if an operator desires. Further, it should be made clear it is not acceptable to advertise this prefix to the Global Internet. - What changes could be made to this proposal to make it more effective? If this becomes policy, I wonder if anyone will think that APNIC or the APNIC Community is recommending this practice, rather than just facilitating the practice for those that want to use it, by making the allocation. Maybe some disclaimer type language would be appropriate. Maybe something like this; This proposal only recommends the assignment of this prefix for the proposed use. The proposal is silent on the details what situations the proposed use is advisable, it may be appropriate in some situations and not others. The proposal merely facilitates the proposed use of the prefix. It is explicitly the responsibility of any network operator contemplating the use of this prefix to consider the pros and cons, and determine for themselves if use of this prefix is appropriate within their network. In other words, use at your own risk. -- ==== 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 version of prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
On 2/13/14, 16:44 , Dean Pemberton wrote: Hi Mike, I like David's way of handling the issue that you raise. By saying that "... it is acceptable to filter this prefix at an administrative boundary, if an operator desires. Further, it should be made clear it is not acceptable to advertise this prefix to the Global Internet." Glad to be of help. :) I'm interested in your comment here regarding the IXP situation. Would 1.2.3.4 being advertised onto an IXP by a willing participant be something that you'd see a problem with? It would certainly be possible to place wording into the policy which places an expectation that operators should filter this at their AS boundary. I'm interested in whether people think this would unreasonably restrict the benefit of some fo the use cases of this prefix. I'm not sure you want to completely prescribe an answer here, it should be a local decision for the community or operator of an IXP. Maybe just suggest that IXPs should consider local policy on the issue, especially for peering with the IXP's route server if their is one. For a direct peering across the exchange it should be up to the two peers to decide. Maybe add a recommendation of ask first as a general rule. Also, if this turns out to work really well, I'm skeptical of that by the way, and it becomes really popular I could see this as a potential service an IXP could provide its members. But, it is way premature to recommend anything like that. Dean -- 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/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] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
> On Feb 27, 2015, at 00:22, Dean Pemberton 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 16:05 , Dean Pemberton wrote: So a "maybe someday" ASN? So anyone who has PI space and doesn't already have an ASN gets allocated one regardless of need. Any new member who gets PI space gets an ASN allocated as a matter of course. 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. If someone gets an ASN, and uses it, when they get PI, they will have a much easier time porting to a new provider, or better yet, becoming multi-homed and/or participating in an IX in the future. So, don't force them to get an ASN, just don't force then wait until they multi-home their PI either. Any additional ASN requested by a member must conform to existing policy. The exact wording of the current policy may or may not be right for the situation, but that is the basic idea. Also, you should still be able to get an ASN to do PA multi-homing, if you are multi-homing with a cut-out from an upstream provider. Is this where we're at? Change the proposal and see where we get to. Yes, please. Why not make it your APNIC membership number and be done with it :). That lowers the barrier even further and means that people wouldn't need assistance applying for them. That's silly, your APNIC Member number should just be your credit card number. :) -- ==== 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 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 Feb 27, 2015, at 21:28, Mark Tinka wrote: >> >> On 28/Feb/15 03:08, David Farmer wrote: >> >> 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. > > True, PI is meant to be portable, which is fine for IPv6 because we have > a lot of address space. > > But don't you worry that you will blow through 4.2 billion ASN's soon if > PI allocation policy evolves to become liberal that 4.2 billion PI > allocations become a reality? > > Mark. If IPv6 PI allocations gets too liberal, the routing system as we know it will implode long before we allocate 4.2 billion ASNs. Restricting the number of ASNs in use in the routing system isn't really going to help that much. The total number of prefixes, PA or PI, has been the primary limiting factor historically. Limiting the portability of PI prefixes by not allocating ASNs won't save the routing system. Only ensuring that the growth in the number of prefixes, both PA and PI, is sustainable and doesn't exceed the growth in the prefix limit for the typical router in use in the Internet at any point in time will keep the current routing system going. We need a new kind of routing system, we've known that for a while. But that is not a policy issues for the RIRs, that is a technology issues for the IETF and the IRTF. I think things like LISP and ILNP are promising in the long run. We just have to keep the current routing system going until those technologies can prove themselves. We do that by keeping total prefix growth sustainable, not by limiting portability of PI prefixes. -- === 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 version of prop-114: Modification in the ASN eligibility criteria
> On Mar 4, 2015, at 17:47, Skeeve Stevens wrote: ... > The APNIC stats are: > > How many ASN - % of Membership > no ASN > 34.06% > 1 > 56.59% > 2 > 5.55% > 3 > 1.78% > 4 > 0.77% > 5 > 0.35% > 6 > 0.28% > 7 > 0.15% > 8 > 0.04% > 10 > 0.13% > more than 10 > 0.31% > Very interesting and useful stats. Are there non-member ASNs, maybe legacy or historic? If so, how many non-members have ASNs? Or, what is the ratio between member and non-member ASNs? I'm not really expecting that much, but on the other hand I don't want to assume either. -- === 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
e members > 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
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
Re: [sig-policy] prop-132-v002: AS0 for Bogons
lutely, its 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
[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
[sig-policy] Re: prop-159-v001: Reduction of minimum IPv6 allocation size form /32 to /36
2 IPv6 address block." > In section 6.1, new LIR accounts (after Februrary, 2019) are only > entitled to receive a maxium allocation of a /23 of IPv4 space - "Since > Thursday, 28 February 2019, each APNIC account holder is only eligible > to receive IPv4 address delegations totalling a maximum /23 from the > APNIC 103/8 IPv4 address pool." > Based on the way APNIC calculates fees (outlined in the APNIC Member Fee > Schedule, document ref APNIC-120) an LIR formed after 2019 with the > maximum IPv4 allocation size and no IPv6 allocation would end up paying > AUD $1,546. > If that same LIR was to request an IPv6 allocation and were awarded the > minimum size of a /32, they would end up paying AUD $2025 - a roughly > 30% fee increase. > 2. Objective of policy change > > By reducing the minimum IPv6 allocation size for LIRs from a /32 to a > /36, an LIR formed after 2019 holding the maximum IPv4 allocation of a > /23 would not be forced to pay increased fees in order to request IPv6. > 3. Situation in other regions > -- > - In ARIN the minimum IPv6 allocation size is a /40 > - In RIPE, fees are not charged based on allocation sizes > - AFRINIC instituted a special policy so existing IPv4 resource holders > will not pay additional fees to deploy IPv6 > 4. Proposed policy solution > -- > I am proposing that section 8.1 be revised to state "The minimum > allocation size for IPv6 address space is /36." > additionally, I am proposing that section 8.2.1 be revised to state "An > account holder that has an IPv4 allocation is eligible for a /36 IPv6 > address block." > 5. Advantages / Disadvantages > -- > Advantages: > The advantage is that small LIRs, or LIRs formed after 2019 would not > face 30% higher fees to request an IPv6 allocation. This may spur IPv6 > adoption in the region. > Disadvantages: > 6. Impact on resource holders > > This would not effect any existing resource holders, only LIRs who are > requesting new IPv6 allocations. > 7. References > -- > - ARIN policy: https://www.arin.net/resources/fees/fee_schedule/ > - Afrinic policy: https://afrinic.net/membership/cost#resource > - APNIC fee calculator: > https://www.apnic.net/get-ip/apnic-membership/how-much-does-it-cost/member-fees-calculator/?feeScheduleYear=2024&ipv4=%2F23&ipv6=%2F36&asn=2 > > > > ___ > 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 - https://mailman.apnic.net/sig-policy@lists.apnic.net/ > To unsubscribe send an email to sig-policy-le...@lists.apnic.net -- === 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: prop-161-v001: Using IPv6 for Internet of Things (IoT) -- correct version
olicy solution > -- > 1. Add a new clause in IPv6 policy. > 8.2.3 Using IPv6 for Internet of Things (IoT) > IPv6 addresses can be allocated to IoT Objects which include electrical > devices and non-electrical items. A default initial IPv6 allocation size > for IoT is a /32. > > 2. Add the following sentence at the end of 8.3.4. Size of subsequent > allocation > An IoT Object will be counted as a normal single host while evaluating > subsequent allocation size for IoT services according to the IPv6 policy. > > 5. Advantages / Disadvantages > - > Advantages: > IPv6 has huge number of IP addresses and IoT needs huge number of IP > addresses. It is a perfect match connects APNIC community with the IoT > industry. Encourage using IPv6 for IoT will help IPv6 deployment in > future Internet. > > Disadvantages: > None > Not to worry about run out of IPv6. The original design of IPv6 was for > Internet of Things. You often hear IPv6 can be assigned to every single > sand in the world :) We can trust APNIC Hostmasters will do the > evaluation properly. > > 6. Impact on resource holders > > No impacts to the current resource holders in the APNIC region. > > > 7. References > -- > > > ___ > 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 - https://mailman.apnic.net/sig-policy@lists.apnic.net/ > To unsubscribe send an email to sig-policy-le...@lists.apnic.net -- === 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: prop-160-v001: Change IPv6 Initial assignment to /44 for Organizations Eligible for /23 IPv4
e for a /48 > IPv6 address block. > If an APNIC account holder wishes to receive an initial allocation or > assignment larger than the sizes described above, the account holder > will need to apply under the alternative criteria described in Section > 8.2.2. and Section 9.1 below. > > > Policy text will be changed : > * An account holder that has a /24 IPv4 assignment is eligible for a /48 > IPv6 address block. > New Policy text will be added : > * An account holder that has a /23 IPv4 assignment is eligible for a /44 > IPv6 address block. > > > 5. Advantages / Disadvantages > -- > Advantages: > Alignment with IPv4 Allocation: Organizations qualifying for a /23 IPv4 > allocation have demonstrably justified a need for a larger address pool. > Aligning the minimum IPv6 allocation with this level reflects similar > requirements in a larger IPv6 address space. > Improved Efficiency for Multihoming and Multi-site Deployments: A /44 > prefix offers greater flexibility for organizations to subnet and manage > their address space effectively across multiple locations or ISPs in a > multihomed environment. > Encouraging IPv6 Adoption: Increasing the minimum allocation cost (in > terms of address space size) can incentivize new organizations to adopt > IPv6, accelerating the overall transition within the region. > > Disadvantages: > > 6. Impact on resource holders > > > 7. References > -- > [1] Section 8.2 Initial IPv6 allocations. > https://www.apnic.net/community/policy/resources#a_h_8_2 > > [2] IPv6 Address Allocation and Assignment Policies for the ARIN Region > https://www.arin.net/participate/policy/nrpm/nrpm.txt > > [3] APNIC Fee Calculation > > https://www.apnic.net/about-apnic/corporate-documents/documents/membership/member-fee-schedule/ > > [4] New Member fee examples > https://www.apnic.net/get-ip/get-ip-addresses-asn/ > > [5] Section 6.1. Minimum and maximum IPv4 delegations > https://www.apnic.net/community/policy/resources#a_h_6_1 > ___ > SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ > To unsubscribe send an email to sig-policy-le...@lists.apnic.net > -- === 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 version: prop-161-v002 - Using IPv6 for Internet of Things (IoT)
ng IPv6 for Internet of Things (IoT) > IPv6 addresses can be allocated to Internet of Things for electronic > smart devices and/or for hosting information of non-electronic items on > the Internet. Initial IPv6 allocation size for IoT will be set to the > minimum IPv6 allocation size at the time of allocation. > > 5. Advantages / Disadvantages > > Advantages: > IPv6 has huge number of IP addresses and IoT needs huge number of IP > addresses. It is a perfect match connects APNIC community with the IoT > industry. Encourage using IPv6 for IoT will help IPv6 deployment in > future Internet. We will create a real Internet of everything based on > IPv6. > > Disadvantages: > None > Not to worry about run out of IPv6. The original design of IPv6 was for > Internet of Things. You often hear IPv6 can be assigned to every single > sand in the world :) We can trust APNIC Hostmasters will do the > evaluation properly. > > 6. Impact on resource holders > --- > No impacts to the current resource holders in the APNIC region. > More new members joining APNIC from the IoT industry will help to reduce > the APNIC membership fee. > > > 7. References > > > _______ > 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 - https://mailman.apnic.net/sig-policy@lists.apnic.net/ > To unsubscribe send an email to sig-policy-le...@lists.apnic.net -- === 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: prop-160-v001: Change IPv6 Initial assignment to /44 for Organizations Eligible for /23 IPv4
Why does justifying a /23 of IPv4 or 512 IPv4 addresses justify a /44 of IPv6? This proposal states it as a fact. Could you explain why this is the case? Thanks On Mon, Aug 19, 2024 at 1:43 AM Rafeeun Noby Babir wrote: > Hi David, > > Thank you for your thoughtful comments on the proposal. I understand your > concerns about the criteria for larger IPv6 allocations and the emphasis on > network-related justification rather than IPv4 holdings or fee structures. > > However, I would like to highlight the situation faced by members from > less developed countries where the implementation of IPv6 is truly > necessary. Many of these new members may not be aware that they are > eligible for a larger IPv6 block based on their circumstances. The explicit > inclusion of this information in the policy is crucial because, without it, > these members might not realize they qualify for more substantial resources. > > While I agree that a detailed network justification is necessary, it's > important to ensure that members understand their eligibility for larger > blocks. *The document you mentioned outlines the requirements for a /23 > IPv4 assignment. If a member meets these requirements of a /23, they are > simultaneously eligible for a larger IPv6 block.* However, due to the > lack of clear guidance in the policy, some members may continue to use IPv6 > in a suboptimal way, such as in multi-homing scenarios, because they don't > have sufficient IPv6 space. > > Ensuring that the policy is clear and accessible can help these members > better utilize IPv6, supporting broader adoption and more efficient network > operations. > > *With Regards,* > *Rafeeun Noby Babir* > > > > On Tue, Aug 6, 2024 at 3:56 AM David Farmer via SIG-policy < > sig-policy@lists.apnic.net> wrote: > >> I do not support this policy as written. Yes, it should be relatively >> easy for organizations to request initial allocations larger than /48. >> However, the justification for this should be based on information about >> their network, like the number of sites it has, from the ARIN policy. It >> should not be based on their IPv4 holdings. And it should most definitely >> not be based on the fee structure. It is logical to align block sizes with >> the fee structure. However, the fee structure should not be the basis for >> the justification of a larger block. >> >> Thanks. >> >> On Mon, Aug 5, 2024 at 4:03 AM Bertrand Cherrier via SIG-policy < >> sig-policy@lists.apnic.net> wrote: >> >>> Dear SIG members, >>> >>> A new proposal "prop-160-v001: Change IPv6 Initial assignment to /44 for >>> Organizations Eligible for /23 IPv4" >>> has been sent to the Policy SIG for review. >>> >>> It will be presented at the Open Policy Meeting (OPM) at APNIC 58 on >>> Friday, 6 September 2024. >>> >>> https://conference.apnic.net/58/program/program/index.html#/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-160 >>> >>> Regards, >>> Bertrand, Shaila, and Anupam >>> APNIC Policy SIG Chairs >>> >>> >>> --- >>> >>> prop-160-v001: Change IPv6 Initial assignment to /44 for Organizations >>> Eligible for /23 IPv4 >>> >>> >>> --- >>> >>> Proposer: Md. Rafeeun Noby Babir (rnba...@gmail.com) >>> >>> >>> 1. Problem Statement >>> >>> The current minimum allocation for Initial IPv6 assignments is a /48 >>> prefix. While this provides a significant pool of addresses, it can
[sig-policy] Re: prop-160-v001: Change IPv6 Initial assignment to /44 for Organizations Eligible for /23 IPv4
First, multihoming justifies an IPv6 assignment of /48 but does not justify a shorter assignment alone. Having multiple sites justifies a /44 of IPv6. Nevertheless, allocating a /23 of IPv4 could mean they need 512 IPv4 addresses at one site, which doesn't justify a /44 of IPv6. You can't know simply from the allocation of a /23 of IPv4 that a /44 of IPv6 is justified. It is possibly justified, but this policy says it is always justified, which is incorrect. Thanks. On Mon, Aug 19, 2024 at 12:36 PM Rafeeun Noby Babir wrote: > Hi David, > > Thank you for your question. The justification for aligning a /23 IPv4 > allocation with a /44 IPv6 allocation is rooted in the specific needs of > network design and best practices. > > When members request a /23 IPv4 allocation, they are not merely seeking > 512 IPv4 addresses. The primary reasons often involve multi-homing or > multi-site deployments, which require multiple /24 blocks. A /24 is the > smallest block that can be advertised on the global Internet, making it > crucial for such use cases. > > In the context of IPv6, a similar situation arises. Multi-homing or > multi-site deployments typically require multiple /48 blocks, as the /48 is > the recommended minimum size for an individual site. To maintain efficiency > and follow best practices, particularly the use of nibble boundaries in > IPv6 addressing, the next logical step after a /48 is a /44. > > Thus, the alignment of a /23 IPv4 allocation with a /44 IPv6 allocation > ensures that members can effectively manage their multi-homing and > multi-site requirements in both IPv4 and IPv6 contexts, adhering to > industry best practices. > > Additionally, this proposal is not just based on a theoretical idea but is > backed by our research on the low IPv6 adoption rates among small or new > ISPs and organizations in less developed countries. Due to the lack of > sufficient routable IPv6 compared to IPv4, many of these organizations are > opting out of dual-stack network plans. By aligning IPv6 allocations with > their actual needs, we aim to encourage broader adoption and support more > sustainable network growth. > > > *With Regards,* > *Rafeeun Noby Babir* > > > On Mon, Aug 19, 2024 at 10:31 PM David Farmer wrote: > >> Why does justifying a /23 of IPv4 or 512 IPv4 addresses justify a /44 of >> IPv6? This proposal states it as a fact. Could you explain why this is the >> case? >> >> Thanks >> >> On Mon, Aug 19, 2024 at 1:43 AM Rafeeun Noby Babir >> wrote: >> >>> Hi David, >>> >>> Thank you for your thoughtful comments on the proposal. I understand >>> your concerns about the criteria for larger IPv6 allocations and the >>> emphasis on network-related justification rather than IPv4 holdings or fee >>> structures. >>> >>> However, I would like to highlight the situation faced by members from >>> less developed countries where the implementation of IPv6 is truly >>> necessary. Many of these new members may not be aware that they are >>> eligible for a larger IPv6 block based on their circumstances. The explicit >>> inclusion of this information in the policy is crucial because, without it, >>> these members might not realize they qualify for more substantial resources. >>> >>> While I agree that a detailed network justification is necessary, it's >>> important to ensure that members understand their eligibility for larger >>> blocks. *The document you mentioned outlines the requirements for a /23 >>> IPv4 assignment. If a member meets these requirements of a /23, they are >>> simultaneously eligible for a larger IPv6 block.* However, due to the >>> lack of clear guidance in the policy, some members may continue to use IPv6 >>> in a suboptimal way, such as in multi-homing scenarios, because they don't >>> have sufficient IPv6 space. >>> >>> Ensuring that the policy is clear and accessible can help these members >>> better utilize IPv6, supporting broader adoption and more efficient network >>> operations. >>> >>> *With Regards,* >>> *Rafeeun Noby Babir* >>> >>> >>> >>> On Tue, Aug 6, 2024 at 3:56 AM David Farmer via SIG-policy < >>> sig-policy@lists.apnic.net> wrote: >>> >>>> I do not support this policy as written. Yes, it should be relatively >>>> easy for organizations to request initial allocations larger than /48. >>>> However, the justification for this should be based on information about >>>> their network, like the number of sites it has, f
