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 <[email protected]> wrote: > > >> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote: >> Hi Owen, >> >>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong <[email protected]> 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 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 <[email protected]> >>>> 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 <[email protected]> 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 <[email protected]> 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 >>>>>> >>>>>> Regards >>>>>> >>>>>> Sumon, Bertrand, Ching-Heng >>>>>> APNIC Policy SIG Chairs >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> prop-132-v001: AS0 for Bogons >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> Proposer: Aftab Siddiqui >>>>>> [email protected] >>>>>> >>>>>> >>>>>> 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 >>>>>> 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 >>>>>> [email protected] >>>>>> https://mailman.apnic.net/mailman/listinfo/sig-policy >>>>> >>>>> * sig-policy: APNIC SIG on resource management policy >>>>> * >>>>> _______________________________________________ >>>>> sig-policy mailing list >>>>> [email protected] >>>>> https://mailman.apnic.net/mailman/listinfo/sig-policy >>> >> >> >> * sig-policy: APNIC SIG on resource management policy >> * >> _______________________________________________ >> sig-policy mailing list >> [email protected] >> https://mailman.apnic.net/mailman/listinfo/sig-policy > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > [email protected] > https://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy
