I don’t tend to regard unallocated as “bogons”, but sure, if this proposal is strictly about unallocated space in the APNIC free pool(s), then I have no problem with that.
Owen > On Aug 15, 2019, at 17:15 , Aftab Siddiqui <aftab.siddi...@gmail.com> wrote: > > Hi Owen, > Just to give you an example, all unallocated address space from 103/8 are > under APNIC's management unless they were transferred to other RIRs and then > reclaimed by that RIR due to whatever reason. This policy covers all > unallocated address space under APNIC's management and asking APNIC to create > AS0 ROAs for all those unallocated addresses. > > Regards, > > Aftab A. Siddiqui > > > On Fri, Aug 16, 2019 at 9:03 AM Owen DeLong <o...@delong.com > <mailto:o...@delong.com>> wrote: > Since we are talking about bigots, other than Unallocated space in RIR > inventory, I’m not sure how you would consider a bogota to be within any > particular RIRs jurisdiction. As such, I was under the impression from the > policy proposal that the intent was for APNIC to issue AS0 ROAs for global > bogons. > > Owen > > > On Aug 15, 2019, at 15:12, Andrew Dul <andrew....@quark.net > <mailto:andrew....@quark.net>> wrote: > >> >> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote: >>> Hi Owen, >>> >>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong <o...@delong.com >>> <mailto:o...@delong.com>> wrote: >>> Looks like IETF wants the global BOGONs to be attested by IANA rather than >>> by an RIR from what you quoted. >>> >>> Yes, for resources not allocated by IANA or marked as Reserved But IANA has >>> nothing to do with resources allocated to RIRs already. >>> >>> Any reason APNIC feels the need to usurp that process? >>> >>> Accordingly to IANA 103/8 was allocated to APNIC and now they don't have >>> unallocated IPv4 address space. >>> 103/8 APNIC 2011-02 whois.apnic.net <http://whois.apnic.net/> >>> https://rdap.apnic.net/ <https://rdap.apnic.net/> ALLOCATED >>> The policy is addressing the unallocated address space within APNIC >>> >> If this policy is only speaking to /8 IPv4 blocks & IPv6 blocks which are >> administered by APNIC, it should be noted that because of inter-RIR >> transfers of IPv4 addresses between regions RIRs other than APNIC are now >> administering sub-portions of the larger IANA allocated blocks. There are >> portions of a /8 for example which are now delegated to other RIRs for >> registrations in those regions. Should it be assumed that those >> sub-portions administered by RIRs now are considered allocated (and not >> bogons) for purposes of this policy? >> >> Andrew >> >>> >>> Owen >>> >>> >>>> On Aug 14, 2019, at 21:58 , Aftab Siddiqui <aftab.siddi...@gmail.com >>>> <mailto:aftab.siddi...@gmail.com>> wrote: >>>> >>>> Hi Owen, >>>> Thanks for your response, sorry for replying late though. >>>> >>>> IMO, IETF has done its part already. >>>> >>>> RFC6483 defines the term “Disavowal of Routing Origination”. >>>> >>>> “A ROA is a positive attestation that a prefix holder has authorized an AS >>>> to originate a route for this prefix into the inter-domain routing system. >>>> It is possible for a prefix holder to construct an authorization where no >>>> valid AS has been granted any such authority to originate a route for an >>>> address prefix. This is achieved by using a ROA where the ROA’s subject >>>> AS is one that must not be used in any routing context. Specifically, AS0 >>>> is reserved by the IANA such that it may be used to identify non-routed >>>> networks >>>> >>>> A ROA with a subject of AS0 (AS0 ROA) is an attestation by the holder of a >>>> prefix that the prefix described in the ROA, and any more specific prefix, >>>> should not be used in a routing context. The route validation procedure >>>> will provide a “valid” outcome if any ROA >>>> matches the address prefix and origin AS even if other valid ROAs would >>>> provide an “invalid” validation outcome if used in isolation. >>>> Consequently, an AS0 ROA has a lower relative preference than any other >>>> ROA that has a routable AS, as its subject. This allows a prefix holder >>>> to use an AS0 ROA to declare a default condition that any route that is >>>> equal to or more specific than the prefix to be considered “invalid”, >>>> while also allowing other concurrently issued ROAs to describe valid >>>> origination authorizations for more specific prefixes.” >>>> >>>> RFC6491 says - "IANA SHOULD issue an AS 0 ROA for all reserved IPv4 and >>>> IPv6 resources not intended to be routed." also "IANA SHOULD issue an AS 0 >>>> ROA for all Unallocated Resources." >>>> >>>> Once allocated to RIRs then IANA can't issue any ROA (they are not doing >>>> it to any resource anyway) but there is unallocated address space with >>>> RIRs, they can issue AS0 ROAs. >>>> >>>> I hope this clarifies your point of IETF's involvement first. >>>> >>>> Regards, >>>> >>>> Aftab A. Siddiqui >>>> >>>> On Sat, Aug 10, 2019 at 6:40 AM Owen DeLong <o...@delong.com >>>> <mailto:o...@delong.com>> wrote: >>>> IMHO, while I’m perfectly fine with APNIC administering this and >>>> maintaining the ROAs, etc., I believe that the decision to allocate AS0 to >>>> this purpose and documentation of this intent should be done through the >>>> IETF and be documented in an STD or RFC. >>>> >>>> I support the idea, but I believe the proper place to start is the IETF. >>>> >>>> Owen >>>> >>>> >>>>> On Aug 9, 2019, at 3:01 AM, Sumon Ahmed Sabir <sasa...@gmail.com >>>>> <mailto:sasa...@gmail.com>> wrote: >>>>> >>>>> >>>>> Dear SIG members, >>>>> >>>>> The proposal "prop-132-v001: AS0 for Bogons" 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-132 >>>>> <http://www.apnic.net/policy/proposals/prop-132> >>>>> >>>>> Regards >>>>> >>>>> Sumon, Bertrand, Ching-Heng >>>>> APNIC Policy SIG Chairs >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> prop-132-v001: AS0 for Bogons >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Proposer: Aftab Siddiqui >>>>> aftab.siddi...@gmail.com <mailto:aftab.siddi...@gmail.com> >>>>> >>>>> >>>>> 1. Problem statement >>>>> -------------------- >>>>> 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) as well as all addresses reserved for private or special use by >>>>> RFCs. See [RFC3330] and [RFC1918]. >>>>> >>>>> As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in the global >>>>> routing table. In the past, several attempts have been made to filter >>>>> out such bogons through various methods such as static filters and >>>>> updating >>>>> them occasionally but it is hard to keep an up to date filters, >>>>> TeamCymru and >>>>> CAIDA provides full bogon list in text format to update such filters. >>>>> TeamCymru >>>>> also provides bogon BGP feed where they send all the bogons via a BGP >>>>> session >>>>> which then can be discarded automatically. Beside all these attempts the >>>>> issue >>>>> of Bogon Advertisement hasn't be resolved so far. >>>>> >>>>> >>>>> 2. Objective of policy change >>>>> ----------------------------- >>>>> The purpose of creating AS0 (zero) ROAs for unallocated address space by >>>>> APNIC >>>>> is to resolve the issue of Bogon announcement. When APNIC issues an AS0 >>>>> ROA for >>>>> unallocated address space in its bucket then it will be marked as >>>>> “Invalid” if >>>>> someone tries to advertise the same address space. >>>>> >>>>> Currently, in the absence of any ROA, these bogons are marked as >>>>> “NotFound”. Since >>>>> many operators have implemented ROV and either planning or already >>>>> discarding “Invalid” >>>>> then all the AS0 ROAs which APNIC will create for unallocated address >>>>> space will be >>>>> discarded as well. >>>>> >>>>> >>>>> 3. Situation in other regions >>>>> ----------------------------- >>>>> No such policy in any region at the moment. >>>>> >>>>> >>>>> >>>>> 4. Proposed policy solution >>>>> --------------------------- >>>>> APNIC will create AS0(zero) ROAs for all the unallocated address space >>>>> in its bucket >>>>> (IPv4 and IPv6). Any resource holder can create AS0 (zero) ROAs for the >>>>> resources they >>>>> have under their account. >>>>> >>>>> A ROA is a positive attestation that a prefix holder has authorised an >>>>> AS to originate a >>>>> route for this prefix whereas, a ROA for the same prefixes with AS0 >>>>> (zero) origin shows >>>>> negative intent from the resource holder that they don't want to >>>>> advertise the prefix(es) >>>>> at this point but they are the rightful custodian. >>>>> >>>>> Only APNIC has the authority to create ROAs for address space not yet >>>>> allocated to the 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 >>>>> <https://tools.ietf.org/rfc/rfc6483.txt> >>>>> RFC6491 - https://tools.ietf.org/rfc/rfc6491.txt >>>>> <https://tools.ietf.org/rfc/rfc6491.txt> >>>>> RFC7607 - https://tools.ietf.org/rfc/rfc7607.txt >>>>> <https://tools.ietf.org/rfc/rfc7607.txt> >>>>> * sig-policy: APNIC SIG on resource management policy >>>>> * >>>>> _______________________________________________ >>>>> sig-policy mailing list >>>>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net> >>>>> https://mailman.apnic.net/mailman/listinfo/sig-policy >>>>> <https://mailman.apnic.net/mailman/listinfo/sig-policy> >>>> * sig-policy: APNIC SIG on resource management policy >>>> * >>>> _______________________________________________ >>>> sig-policy mailing list >>>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net> >>>> https://mailman.apnic.net/mailman/listinfo/sig-policy >>>> <https://mailman.apnic.net/mailman/listinfo/sig-policy> >>> >>> >>> * sig-policy: APNIC SIG on resource management policy >>> * >>> _______________________________________________ >>> sig-policy mailing list >>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net> >>> https://mailman.apnic.net/mailman/listinfo/sig-policy >>> <https://mailman.apnic.net/mailman/listinfo/sig-policy>* >>> sig-policy: APNIC SIG on resource management policy * >> _______________________________________________ >> sig-policy mailing list >> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net> >> https://mailman.apnic.net/mailman/listinfo/sig-policy >> <https://mailman.apnic.net/mailman/listinfo/sig-policy>* >> sig-policy: APNIC SIG on resource management policy * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net> > https://mailman.apnic.net/mailman/listinfo/sig-policy > <https://mailman.apnic.net/mailman/listinfo/sig-policy>
* 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
