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