Dear SIG members
A new version of the proposal "prop-143-v002: ASN to
Customer" has been sent
to the Policy SIG for review.
Information about earlier versions is available from:
http://www.apnic.net/policy/proposals/prop-143
You are encouraged to express your views on the
proposal:
- Do you support or oppose the proposal?
- Is there anything in the proposal that is not clear?
- What changes could be made to this proposal to make it more effective?
Please find the text of the proposal below.
Kind Regards,
Bertrand, Ching-Heng and Shaila
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-143-v002: ASN to Customer
---------------------------------------------------------------
Proposer: Jordi Palet Martínez (jordi.palet@theipv6company.com)
Anupam Agrawal (anupamagrawal.in@gmail.com)
1. Problem statement
--------------------
Section 12.4 allows a LIR to provide an ASN to a customer, but
doesn’t
allow that ASN to be used by the customer if ceases to receive
connectivity, even if the customer gets connectivity from another
LIR
or becomes a direct APNIC/NIR customer. It also contradicts the
options for a transfer.
This generates problems in many situations, such as, for example:
• Bankruptcy of the LIR that originally provided the ASN, even
if other upstream providers where that ASN was being used still
provide the connectivity.
• The customer becomes a direct APNIC/NIR member.
• The LIR change providers (including the one that provided the
ASN) but the customer network is the same.
The ASNs aren’t a resource that it is subjected to exhaustion in
the
medium-long term, but it is also understandable that ASNs not used
should be returned.
However, it doesn’t make sense that an ASN that has been assigned
to a
customer needs to be returned if business situations change, but
the
network using that ASN is still connected to Internet and willing
to
use the same ASN.
It should be noticed that the criteria for obtaining the ASN was
already initially fulfilled by that customer, not the LIR, so
that’s
granted.
This is especially relevant when organizations do the transition
to
IPv6, as they may have been customers from several upstream
providers
and not have IPv4 allocations, but they need those for IPv6 PI,
which
will be directly assigned by APNIC (or the relevant NIR), and
consequently they need to keep an ASN.
This should not be considered a transfer in the sense that the ASN
was
already used by that organization, so there is no actually being
transferred from one customer to another.
2. Objective of policy change
-----------------------------
Simplify the process and avoid a ASN change in certain cases,
recognize a new use case for transfer and most importantly, record
the
transfer criteria in the policy document.
3. Situation in other regions
-----------------------------
Other RIRs don’t have explicit rules or restrictions on those
cases,
at least not clearly stated in policies, but the transfer of ASN
is
much simpler, so it fulfills what this proposal is trying to
achieve.
4. Proposed policy solution
---------------------------
Proposed text:
12.4. Providing ASN to customer
Assignments to organizations that will provide the ASN to one of
its
customers are subject to the following additional terms:
1. The customer that will actually use the ASN must meet the
criteria in Section 12.0.
2. The requesting organization is responsible for maintaining
the
registration described in Section 5.3.3. on behalf of the
customer.
3. If the customer ceases to receive connectivity from the
requesting organization it must return the ASN. The requesting
organization is expected to enter into an agreement with the
customer
to this effect.
4. Any ASNs returned to the requesting organization must then
be
returned to APNIC or the relevant NIR.
5. Alternatively, the same ASN could be registered:
• via another transfer to another APNIC/NIR member (upstream
provider connecting that customer), or
• directly by the customer in cases when they become an
APNIC/NIR member and receives the ASN via transfer.
5. Advantages / Disadvantages
-----------------------------
Advantages:
Fulfilling the objective above indicated. Avoids the original ASN
user
to reconfigure devices and provides “stability” of the stats for
that
ASN (the traffic is from the same customer).
Disadvantages:
It may be perceived as a transfer, but actually is not, because
the
user of the ASN is the same as the one that was originally
assigned to.
6. Impact on resource holders
-----------------------------
None.
7. References
-------------------------------------------------------
None.
