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/ 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

        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
        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 <mailto: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 <mailto: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