Hi Owen,

On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong <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 https://rdap.apnic.net/ ALLOCATED
The policy is addressing the unallocated address space within APNIC


>
> Owen
>
>
> On Aug 14, 2019, at 21:58 , Aftab Siddiqui <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> 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> 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
>>            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
>> 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
>>
>>
>> *              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:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to