Fair enough. I tend to think of Bogons as “Those addresses which shouldn’t be 
advertised _EVER_” (e.g. 10.0.0.0/8) while I tend to think of Unallocated as 
being more transient in nature.

I realize that makes 224.0.0.0/4 classification as a bogon a bit of a grey 
area, while including all unallocated space makes a cleaner definition.

I suppose part of the reason for that was I always tended to maintain bogons 
and unallocated as separate lists in ACLs and I usually kept the unallocated 
one in the dynamic configuration (in Juniper land) since it tended to need 
frequent update.

Owen


> On Aug 21, 2019, at 16:02 , Aftab Siddiqui <aftab.siddi...@gmail.com> wrote:
> 
> Hi Owen,
> 
> On Thu, Aug 22, 2019 at 7:10 AM Owen DeLong <o...@delong.com 
> <mailto:o...@delong.com>> wrote:
> I don’t tend to regard unallocated as “bogons”,
> 
> Why is that? 
> RFC3871 <https://tools.ietf.org/html/rfc3871> - Bogon: 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, APNIC...) 
> as well as all addresses reserved for private or special use by RFCs.
>  
> but sure, if this proposal is strictly about unallocated space in the APNIC 
> free pool(s), then I have no problem with that.
> 
> Yes, the policy is strictly talking about "unallocated address space" in 
> APNIC free pool.
>  
> 
> Owen
> 
> 
>> On Aug 15, 2019, at 17:15 , Aftab Siddiqui <aftab.siddi...@gmail.com 
>> <mailto: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

Reply via email to