Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Satoru Tsurumaki]

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-132, based
on a meeting we organized on 21th Aug to discuss these proposals.
Please note that these discussion is based on the first Proposal, prop-132-0001.

Many participants basically support this proposal.
But If an incorrect ROA is created due to a miss-operation or
unexpected trouble, not only the quality of the network will be
degraded, but it may adversely affect the deployment of RPKI in this
community. We hope careful deployment such as having a sufficient test
period if this proposal reach consensus.

Best Regards,

Satoru Tsurumaki
JPOPF-ST

2019年8月9日(金) 19:02 Sumon Ahmed Sabir :

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

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Aftab Siddiqui]

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  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 
> wrote:
>
> Hi Owen,
>
> On Thu, Aug 22, 2019 at 7:10 AM Owen DeLong  wrote:
>
>> I don’t tend to regard unallocated as “bogons”,
>>
>
> Why is that?
> 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 
>> 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  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  wrote:
>>>
>>>
>>> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
>>>
>>> Hi Owen,
>>>
>>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  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 
 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 

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Owen DeLong]

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  wrote:
> 
> Hi Owen,
> 
> On Thu, Aug 22, 2019 at 7:10 AM Owen DeLong  > wrote:
> I don’t tend to regard unallocated as “bogons”,
> 
> Why is that? 
> 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 > > 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 > > 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 > > wrote:
>> 
>>> 
>>> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
 Hi Owen,
 
 On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong >>> > 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  > 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 

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Aftab Siddiqui]

Hi Owen,

On Thu, Aug 22, 2019 at 7:10 AM Owen DeLong  wrote:

> I don’t tend to regard unallocated as “bogons”,
>

Why is that?
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 
> 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  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  wrote:
>>
>>
>> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
>>
>> Hi Owen,
>>
>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  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 
>>> 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 

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Owen DeLong]

I don’t tend to regard unallocated as “bogons”, but sure, if this proposal is 
strictly about unallocated space
in the APNIC free pool(s), then I have no problem with that.

Owen


> On Aug 15, 2019, at 17:15 , Aftab Siddiqui  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  > 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  > wrote:
> 
>> 
>> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
>>> Hi Owen,
>>> 
>>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong >> > 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 >>> > 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 >>> > wrote:

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Aftab Siddiqui]

Hi Andrew,
Good suggestion, it makes more sense and very well noted. I will made the
change accordingly. Let me see if any other suggestions comes out later
today otherwise I will update the policy.

Regards,

Aftab A. Siddiqui


On Fri, Aug 16, 2019 at 10:13 AM Andrew Dul  wrote:

> Hello!
> On 8/15/2019 5:00 PM, Aftab Siddiqui wrote:
>
> Hi Andrew,
>
>>
>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  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?
>>
> The policy is for unallocated address space (v4 and v6) under APNIC
> bucket. If the resources has been transferred to other RIRs means they are
> not unallocated anymore. If a /8 has been chopped by IANA and allocated to
> multiple RIRs e.g. 202/8 then APNIC will create AS0 ROAs for only those
> unallocated address space under APNIC's management. Any address space which
> is not under APNIC's resource bucket is not covered by this policy. I hope
> that answers your question.
>
>
> I'd like to suggest that the text "in its bucket" is not very well
> defined.  Can I suggest this updated policy text to clarify the intent as
> you've described.
>
>
> APNIC will create AS0(zero) ROAs for all the unallocated (IPv4 and IPv6)
> address space for which APNIC is the current administrator.  APNIC will not
> create AS0(zero) ROAs for any block which is currently allocated or
> transferred to another RIR, or is a private, special purpose, or any other
> IANA reserved or unallocated block.
>
>
> Hope this helps,
>
> Andrew
>
*  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

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Aftab Siddiqui]

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  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  wrote:
>
>
> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
>
> Hi Owen,
>
> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  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 
>> 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  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  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 

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Andrew Dul]

Hello!

On 8/15/2019 5:00 PM, Aftab Siddiqui wrote:

Hi Andrew,



On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong 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 
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?

The policy is for unallocated address space (v4 and v6) under APNIC 
bucket. If the resources has been transferred to other RIRs means they 
are not unallocated anymore. If a /8 has been chopped by IANA and 
allocated to multiple RIRs e.g. 202/8 then APNIC will create AS0 ROAs 
for only those unallocated address space under APNIC's management. Any 
address space which is not under APNIC's resource bucket is not 
covered by this policy. I hope that answers your question.


I'd like to suggest that the text "in its bucket" is not very well 
defined.  Can I suggest this updated policy text to clarify the intent 
as you've described.



APNIC will create AS0(zero) ROAs for all the unallocated (IPv4 and IPv6) 
address space for which APNIC is the current administrator.  APNIC will 
not create AS0(zero) ROAs for any block which is currently allocated or 
transferred to another RIR, or is a private, special purpose, or any 
other IANA reserved or unallocated block.



Hope this helps,

Andrew

*  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

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Aftab Siddiqui]

Hi Andrew,

>
> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  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?
>
The policy is for unallocated address space (v4 and v6) under APNIC bucket.
If the resources has been transferred to other RIRs means they are not
unallocated anymore. If a /8 has been chopped by IANA and allocated to
multiple RIRs e.g. 202/8 then APNIC will create AS0 ROAs for only those
unallocated address space under APNIC's management. Any address space which
is not under APNIC's resource bucket is not covered by this policy. I hope
that answers your question.
*  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

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Andrew Dul]

On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:

Hi Owen,

On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong > 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
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 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
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 

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Aftab Siddiqui]

Hi Owen,

On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  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 
> 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  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  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 

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Owen DeLong]

Looks like IETF wants the global BOGONs to be attested by IANA rather than by 
an RIR from what you quoted.

Any reason APNIC feels the need to usurp that process?

Owen


> On Aug 14, 2019, at 21:58 , Aftab Siddiqui  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  > 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 > > 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 

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Md. Abdul Awal]

Hi Aftab-bhai,

While I totally support the proposal, I think this will only isolate
BOGON/Martian routes in AP region and so all the other regions must do
the same to make the idea fully functional. By that, I indicate of a
global policy, may be at the NRO level. But anyway, at least it can be
started from this region.

BR//Awal


On 15/8/19 10:58 AM, Aftab Siddiqui 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  > 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 > > 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 

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Aftab Siddiqui]

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

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Owen DeLong]

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