Ok I get your point now. During my ops days I used to manage "Martians"
(reserved blocks/special use blocks) and "Bogons" (unallocated address
blocks) prefix filters :)

Regards,

Aftab A. Siddiqui


On Thu, Aug 22, 2019 at 9:09 AM Owen DeLong <o...@delong.com> wrote:

> 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> 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>
>> 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> 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> 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> 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 <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 
>>> listsig-policy@lists.apnic.nethttps://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
>>
>>
>>
>
*              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