________________________________
From: sig-policy-boun...@lists.apnic.net <sig-policy-boun...@lists.apnic.net> 
on behalf of JORDI PALET MARTINEZ <jordi.pa...@consulintel.es>
Sent: Monday, 26 August 2019 6:19 PM
To: Policy SIG <sig-pol...@apnic.net>
Subject: Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments


Hi Javed,



I think you’re getting something wrong.



Policies aren’t there so APNIC can verify “everything” to “every” member. This 
will be impossible.



Policies are there so everybody know the rules, and try their best to avoid 
breaking them.


So is anyone breaking the current policy? can you provide examples?



Policies are there to avoid bad-intentions from bad-Internet actors, in order 
to protect the majority (the good ones).



If we only accept policies when they can be verified, then we will have an 
empty policy book :-)



If APNIC does a verification, for whatever reason (any suspicius, a claim from 
another member, etc.), and a rule is broken, APNIC should take measures if the 
member doesn’t correct it. In some cases those measures may mean member 
closure, resource recovery, etc. This is a completely different discussion 
which has policy and service agreement implications.



Please, note before continue reading that this only affects end-user direct 
assignments by APNIC or the NIRs. Not clarifiying this caused some confusion in 
the discussion of the last meeting. So if you’re an ISP (I’m not sure if that’s 
your case), this proposal doesn’t affect you.



It only affect you, if you are getting a direct assignment from APNIC or any of 
the NIRs.


I clearly understand that and I am not speaking for myself nor my organisation.



The fact here is that if, for example, an university, which got a direct 
assignment from APNIC, is providing the students public addresses (IPv4) or 
global addresses (IPv6), it is against the policy.


If the students are connecting to the university infrastructure to access 
resources, university is not breaking the current policy because the address 
space is still used for their infrastructure and not sub-assigned to students.



In the case of IPv4, the solution is easy, use NAT and private addresses (but 
not all the universities do that). However in IPv6 this is not the solution, we 
don’t have NAT.


Indeed everyone use NAT but the policies are not promoting to use NATs. Its a 
choice that the network providers make.



I can put many other similar examples (remember again, this is only the case 
when the addresses are directly assigned to the end-user by APNIC or the NIR, 
not by an ISP): a point to point link from the university to another network, 
an employee getting addresses from a company, thir party companies offering 
services to that company or university, a municipality offering WiFi to 
citizens, etc.


Employees getting addresses from a company is same as students in the 
university, as above.



The proposal solves both cases, the IPv4 and the IPv6 one.



Note that this has been already corrected in all the other RIRs (ARIN, AFRINIC, 
LACNIC and RIPE). All them had the same problem in their policy text.


Ok but RIR regions are not all same and that's why we have an RIR for each 
region. If its corrected in one RIR doesn't mean that other RIR community has 
to follow that. Each RIR community can have its own discussion. Right?


J Khan



Regards,

Jordi

@jordipalet







El 23/8/19 16:01, "Javed Khan" 
<sig-policy-boun...@lists.apnic.net<mailto:sig-policy-boun...@lists.apnic.net> 
en nombre de javedkha...@outlook.com<mailto:javedkha...@outlook.com>> escribió:



I do not support this proposal. Intention is good but no one is really 
concerned nor can verify this in practice. I think the current policy text is 
good.



Kind regards

Javed Khan

MSCE and CCSP



________________________________

From: sig-policy-boun...@lists.apnic.net <sig-policy-boun...@lists.apnic.net> 
on behalf of Sumon Ahmed Sabir <sasa...@gmail.com>
Sent: Saturday, 10 August 2019 10:33 PM
To: Policy SIG <sig-pol...@apnic.net>
Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments



Dear SIG members

A new version of the proposal "prop-124: Clarification on Sub-Assignments"
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.

Information about earlier versions is available from:
https://www.apnic.net/community/policy/proposals/prop-124

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,

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs


----------------------------------------------------------------------

prop-124-v006: Clarification on Sub-Assignments

----------------------------------------------------------------------

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


1. Problem Statement
--------------------

Note that this proposal is ONLY relevant when end-users obtain direct
assignments
from APNIC, or when a LIR obtains, also from APNIC, and assignment for
exclusive
use within its infrastructure. Consequently this is NOT relevant in case
of LIR
allocations.

When the policy was drafted, the concept of assignments/sub-assignments
did not
consider a practice very common in IPv4 which is replicated and even
amplified
in IPv6: the use of IP addresses for point-to-point links or VPNs.

In IPv4, typically, this is not a problem if NAT is being used, because
the assigned
addresses are only for the WAN link, which is part of the infrastructure
or interconnection.

In the case of IPv6, instead of unique addresses, the use of unique
prefixes
(/64) is increasingly common.

Likewise, the policy failed to consider the use of IP addresses in
hotspots hotspots
(when is not an ISP, for example, associations or community networks),
or the use of
IP addresses by guests or employees in Bring Your Own Device (BYOD) and
many other
similar cases.

One more case is when an end-user contracts a third-party to do some
services in their
own network and they need to deploy their own devices, even servers,
network equipment,
etc. For example, security surveillance services may require that the
contractor provides
their own cameras, recording system, even their own firewall and/or
router for a dedicated
VPN, etc. Of course, in many cases, this surveillance system may need to
use the addressing
space of the end-user.

Finally, the IETF has recently approved the use of a unique /64 prefix
per interface/host
(RFC8273) instead of a unique address. This, for example, allows users
to connect to a hotspot,
receive a /64 such that they are “isolated” from other users (for
reasons of security,
regulatory requirements, etc.) and they can also use multiple virtual
machines on their
devices with a unique address for each one (within the same /64).


2. Objective of policy change
-----------------------------

Section 2.2.3. (Definitions/Assigned Address Space), explicitly
prohibits such assignments,
stating that “Assigned ... may not be sub-assigned”.

It also clarifies that the usage of sub-assignments in ISPs, data
centers and similar cases
is not allowed, according to the existing practices of APNIC.


3. Situation in other regions
-----------------------------

This situation, has already been corrected in AFRINIC, ARIN, LACNIC and
RIPE.


4. Proposed policy solution
---------------------------

Current Text
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or
end-user,
for specific use within the Internet infrastructure they operate.
Assignments must
only be made for specific, documented purposes and may not be sub-assigned.


New text:
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or
end-user,
for exclusive use within the infrastructure they operate, as well as for
interconnection
purposes.

The assigned address space must only be used by the original recipient
of the assignment,
as well as for third party devices provided they are operating within
said infrastructure.

Therefore, sub-assignments to third parties outside said infrastructure
(for example
using sub-assignments for ISP customers), and providing addressing space
to third
parties in data-centers (or similar cases), are not allowed.


5. Advantages / Disadvantages
-----------------------------

Advantages:
Fulfilling the objective above indicated and making sure to match the
real situation
in the market.


Disadvantages:
None foreseen.


6. Impact on resource holders
-----------------------------
None.

7. References
-------------
Links to RIPE policy amended and new policy proposal submitted.

* 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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

*              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