Hi Javed,

 

I actually think this is in the other way around.

 

I believe you’re confusing different terms, clearly described in the 
definitions section of the policy manual:

 

2.2.1. Delegated address space

APNIC "delegates" addresses to its account holders. These delegations can be 
for use on the organization's own infrastructure (an "assignment") or for 
subsequent delegation by the organization to its customers (an "allocation").

 

2.2.2. Allocated address space

Allocated address space is address space that is distributed to IRs or other 
organizations for the purpose of subsequent distribution by them.

 

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.

 

This policy is only relevant to “assigments”.

 

When an ISP (LIR) is getting addresses from APNIC for further distribution to 
customers, that space falls into the definition of “allocation”, so it is fine 
to further dirstribute it to other organizations.

 

When an ISP (LIR) is getting “assigned” space from ACPNIC, is not for 
re-distribution. This is what I’m triyng to clarify.

 

The fact that you are confused, I think, demonstrates that the actual text is 
subjected to multiple interpretations.

 

As an ISP/LIR, which the current text, for different people reading it, a p2p 
link may be or not considered part of the infratructure. Perhaps you can say, 
it is ok to use for a p2p if the CPE is from the ISP, but otherwise not.

 

My text clarify all the possible cases.

 

Regards,

Jordi

@jordipalet

 

 

 

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

 

Yes but the proposed text is not clear. In with the current policy text, LIRs 
are not allowed to make sub-assignments from their assigned address space 
outside of their infrastructure. So I do not support this change in policy.

 

J Khan

 

From: sig-policy-boun...@lists.apnic.net <sig-policy-boun...@lists.apnic.net> 
on behalf of Owen DeLong <o...@delong.com>
Sent: Saturday, 24 August 2019 12:45 AM
To: Simon Sohel Baroi / Global Business / 01847102243 / 
<simon.ba...@fiberathome.net>
Cc: Sumon Ahmed Sabir <sasa...@gmail.com>; Policy SIG <sig-pol...@apnic.net>
Subject: Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments 

 

I think the current text isn’t really a problem because reasonable people apply 
a reasonable interpretation of intent rather than the literal meaning. 

 

The proposal brings literal meaning more in line with well understood intent. 

 

While I don’t believe there is an actual problem to solve here, I do think the 
proposal provides greater clarity in the language and therefore support it. 

 

Owen

 


On Aug 23, 2019, at 01:11, Simon Sohel Baroi / Global Business / 01847102243 / 
<simon.ba...@fiberathome.net> wrote:

Dear Sir,

 

Also, Requesting to the Author to represent the Proposal with Example and 
Graphical Representation.

The example should have comparison with Present situation and the Propose 
Solution of the problem.

 

 

- with regards

 

SIMON.

 

On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir <sasa...@gmail.com> wrote:

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


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


 

-- 

Simon Sohel Baroi  |  AGM  |  International Gateway and Cable  |
Cell : +880-181-7022207  |  Desk : +880-9666776677 Ext-1702  |   

Mail : simon.ba...@fiberathome.net  |  Skype : tx.fttx  |

Reduce. Reuse. Recycle. Respect. It's the little things that really can make a 
difference.

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