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 im

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

[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 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] prop-131-v001: Editorial changes in IPv6 Policy

[Sumon Ahmed Sabir]

Dear SIG members,

The proposal "prop-131-v001: Editorial changes in IPv6 Policy" 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-131

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs


--

prop-131-v001: Editorial changes in IPv6 Policy

--

Proposer: Jordi Palet Martínez
   jordi.pa...@theipv6company.com


1. Problem Statement


This proposal suggests multiple (mainly) editorial changes in the IPv6
Policy.
The intent is to remove non-necessary text, and simplify the policy.

Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is
removed,
as it is something obvious that operators need to assign some space for
different
parts of their own infrastructure.

Section 5.2.4.3. explicitly states that it was drafted at a time when
there was no
experience with IPv6 deployment, which is this is longer the case, it
does not make
sense to have NIR/RIR to evaluate each instance where an LIR has an End
User whose
end site(s) requires a shorter prefix than a /48.

Finally, section 10.1.4.1. is reworded, taking advantage of some of the
editorial
changes in the precedent sections, so to avoid duplicating text.



2. Objective of policy change
-

Fulfil the above indicated edits.


3. Situation in other regions
-

A similar proposal has been submitted to RIPE.


4. Proposed policy solution
---

Current Text
5.2.4.2. Assignment address space size

...

End-users are assigned an end site assignment from their LIR or ISP. The
exact size of
the assignment is a local decision for the LIR or ISP to make, using a
minimum value of
a /64 (when only one subnet is anticipated for the end site) up to the
normal maximum of
/48, except in cases of extra large end sites where a larger assignment
can be justified.

...


New Text
5.2.4.2. Assignment address space size

...

End Users are assigned an end site assignment from their LIR or ISP. The
size of the
assignment is a local decision for the LIR or ISP to make, using a value
of "n" x /64.
BCOP RIPE690 Section 4.2, provides guidelines about this.

...

==

Current Text
5.2.4.3. Assignment of multiple /48s to a single end site

When a single end site requires an additional /48 address block, it must
request the
assignment with documentation or materials that justify the request.
Requests for multiple
or additional /48s will be processed and reviewed (i.e., evaluation of
justification) at
the RIR/NIR level.

Note: There is no experience at the present time with the assignment of
multiple /48s to
the same end site. Having the RIR review all such assignments is
intended to be a temporary
measure until some experience has been gained and some common policies
can be developed.
In addition, additional work at defining policies in this space will
likely be carried out
in the near future.


New Text
5.2.4.3. Assignment of multiple /48s to a single end site

Assignment larger than /48 (shorter prefix) or additional assignments
exceeding a total of
/48 must be made based on address usage, or because different routing
requirements exist
for additional assignments.

In case of a review or when making a request for a subsequent
allocation, the LIR must
be able to present documentation justifying the need for assignments
shorter than a
/48 to a single End-Site.



Current Text
5.2.4.4. Assignment to operator's infrastructure

An organization (ISP/LIR) may assign a /48 per PoP as the service
infrastructure of an
IPv6 service operator. Each assignment to a PoP is regarded as one
assignment regardless
of the number of users using the PoP. A separate assignment can be
obtained for the
in-house operations of the operator.


New Text
(removed and following sections renumbered accordingly)

=

Current Text
10.1.4.1. Initial assignment

...

The minimum assignment made under this policy is