Re: [sig-policy] Prop124 version 4

  • To: Satoru Tsurumaki <satoru.tsurumaki@g.softbank.co.jp>, SIG policy <sig-policy@apnic.net>
  • Subject: Re: [sig-policy] Prop124 version 4
  • From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
  • Date: Tue, 11 Sep 2018 14:55:15 +1100
  • Delivered-to: sig-policy@clove.apnic.net
  • Dkim-signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1536638129; x=1537242929; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=i1i40/hmsRjzFa3T3ZoqG17t+0XHEdxFRU DH9gtTgU0=; b=OZ64mG9V5Bp7KmCrK0oK552hOsC2HaCX53eE3Zq611IsrnieeK 4+OxYDREkveodWcSzdQLLrcZ7Jy9yfJGqqW7NrFUUU0BfW0mfKUh9vSodUDpvs5p 1m0bmZop/rEh7qnCEfT2MA1VwA6A4ccNr3KMbCNvEVgrlYN49RBckAT+U=
  • In-reply-to: <CAHXx+kSu+TPqhKavrQVcQN4=bz4Q_vEO4kvpx74sENc6144NBQ@mail.gmail.com>
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy/>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <https://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <https://mailman.apnic.net/mailman/options/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • References: <6CCF35B5-45D2-4E4F-8819-E035C6D6FB0D@micrologic.nc> <CAHXx+kSu+TPqhKavrQVcQN4=bz4Q_vEO4kvpx74sENc6144NBQ@mail.gmail.com>
  • Thread-topic: [sig-policy] Prop124 version 4
  • User-agent: Microsoft-MacOutlook/10.10.0.180812

    • Hi Satoru,

       

      Thanks for commenting on this.

       

      The current proposal text has not examples, I think it is quite neutral in this aspect:

       

      Providing addressing space to third party devices including addresses for

      point-to-point links and/or non-permanently providing addressing space to third

      parties, for use on a network managed and operated by the assignment holder,

      shall not be considered a sub-assignment.

       

      The provision of addressing space for permanent or semi-permanent connectivity,

      such as broadband services, is still considered a sub-assignment.

       

      I think having the examples in the “objective” of the policy proposal is needed to clarify the reason for it. You don’t think so?


      Regards,

      Jordi

       

       

       

      De: <sig-policy-bounces@lists.apnic.net> en nombre de Satoru Tsurumaki <satoru.tsurumaki@g.softbank.co.jp>
      Fecha: martes, 11 de septiembre de 2018, 14:02
      Para: SIG policy <sig-policy@apnic.net>
      Asunto: Re: [sig-policy] Prop124 version 4

       

      Dear Colleagues,

       

      I am Satoru Tsurumaki from Japan Open Policy Forum.

       

      I would like to share key feedback in our community for prop-124,

      based on a meeting we organised on 22nd Aug to discuss these proposals.

       

      Many supporting opinions were expressed on this proposal.

      However, also many concerning comment was expressed to explain the specific examples.

      For this matter, the same opinion was given also at JPOPM34.

       

        - It is better to stop specific examples because they tend to fall into discussion of adding / not applying / not applicable.

        - I think that specific examples should be stated in the guidelines rather than policies.


      Regards,

      Satoru Tsurumaki

       

       

      2018-09-09 18:37 GMT+11:00 Bertrand Cherrier <b.cherrier@micrologic.nc>:

      Dear SIG members

      A new version of the proposal "prop-124: Clarification on IPv6 Sub-Assignments"
      has been sent to the Policy SIG for review.

      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-v004: Clarification on IPv6 Sub-Assignments


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

      1. Problem Statement

      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 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,
      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”.

      https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space

      This proposal clarifies this situation in this regard and better define the
      concept, particularly considering new uses of IPv6 (RFC 8273), by means of
      a new paragraph.

      3. Situation in other regions

      This situation, has already been corrected in RIPE, and the policy was updated
      in a similar way, even if right now there is a small discrepancy between the
      policy text that reached consensus and the RIPE NCC Impact Analysis. A new
      policy proposal has been submitted to amend that, and the text is the same
      as presented by this proposal at APNIC. Same text has also been submitted
      to AfriNIC, LACNIC and ARIN.

      4. Proposed policy solution

      Add a new paragraph after the existing one in 2.2.3
      https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space

      Actual 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 specific use within the Internet infrastructure they operate. Assignments must
      only be made for specific, documented purposes and may not be sub-assigned.

      Providing addressing space to third party devices including addresses for
      point-to-point links and/or non-permanently providing addressing space to third
      parties, for use on a network managed and operated by the assignment holder,
      shall not be considered a sub-assignment.

      The provision of addressing space for permanent or semi-permanent connectivity,
      such as broadband services, is still considered a sub-assignment.

      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.

      Cordialement,


      Bertrand Cherrier
      Administration Systèmes - R&D
      Micro Logic Systems
      b.cherrier@micrologic.nc
      https://www.mls.nc
      Tél : +687 24 99 24
      VoIP : 65 24 99 24
      SAV : +687 36 67 76 (58F/min)



      *              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.consulintel.es
      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.