[rpd] Proposal: Clarification on temporary resource usage

Fri Dec 21 14:50:44 UTC 2018

Hi Willy,

Please see my comments below in-line.

Don't get me wrong, I'm for the IPv6 deployment, but we must not act as an "enforcing" regulator (at least not at the time being, may be in a couple of years from now for the laggards to react).

Remember that a conference is going to depend on ISPs ... So they could, maximum, hire IPv6 trained folks to deploy a dual-stack network, but if the ISP is not providing IPv6 transit, they need to setup a tunnel.

Regards,
Jordi

-----Mensaje original-----
De: Ernest Byaruhanga <ernest at afrinic.net>
Fecha: viernes, 21 de diciembre de 2018, 8:26
Para: "rpd >> AfriNIC Resource Policy" <rpd at afrinic.net>
Asunto: [rpd] Proposal: Clarification on temporary resource usage

    A new policy proposal has been received:

    Title: Clarification on temporary resource usage
    ID:AFPUB-2018-GEN-004-DRAFT01
    Author: Manga Willy Ted
    URL: https://afrinic.net/policy/2018-gen-004-d1#proposal

    The proposal introduces modifications to CPM 9.0 which deals with issuance of number resources for temporary use (such as for conferences and experiments).

    The proposal has been published at : 
    https://afrinic.net/policy/2018-gen-004-d1#proposal 
    (Text in orange color depicts changes to current policy text)

    Plain text version:

    ————————————
    Clarification on temporary resource usage 
    ————————————

    1.0 Summary of the problem being addressed by this proposal

    With IPv4 exhaustion coming, IPv4 resource assignments need better management because of scarcity. For instance, what happens if some entities request a /20 worth of IPv4 for temporary usage during soft landing phase 2? With current IPv6 evolution, we think entities requesting temporary resources should deploy more IPv6 prefixes than IPv4 prefixes.

[Jordi] While I agree with the intent, I think it can be even more restrictive. If you need IPv4 addresses for a conference or similar, use NAT and consequently the minimum routable prefix, such as /24 or even a smaller block. IPv6 as much as you need.

    2.0 Summary of how this proposal addresses the problem

    This proposal aims to restrict the size of IPv4 resource requests for temporary use such as conferences and meetings and in addition, encourages IPv6 usage for those purposes. We believe that IPv6 is now mature enough to be deployed for this kind of usage.

    Any IPv4 space requested for temporary usage should not be more than /22 - especially for meetings and events. The requesting entity should use IPv6-only on their networks and deploy IPv4 at the edge of the network using an IPv6 transition mechanism.

[Jordi] This is broken. We must not mandate IPv6-only, even less while it is not clearly defined what it means in this paragraph. You may get a conference in a country where the ISP doesn't have IPv4. You need to make a tunnel, so you need to have IPv4. That means that if you are requesting addressing space and ASN, is because the conference will have its own BGP. Big conferences (IETF, ICANN, others), have already their own ASN, IPv4/IPv6 blocks, but small ones, need to rely in the ISP (if the ISP has at least one IPv4 available for the "on-site" NAT).
If you mean that they MUST offer IPv6-only in the conference LAN, this is not good again. There may be requiring applications (videoconferencing, streaming, etc.), which is IPv4-only and using literals, etc. This is not something in the hands of the organizer to sort out.
If you want to say that they must have dual-stack in the conference LANs, even if using and IPv4-aaS such as 464XLAT, that will be fine. Today everybody is able to have dual-stack in a conference, there is no excuse for that, even if you need to setup a free HE tunnel.

    Lastly, we believe the title of this section of the CPM should reflect exactly the fact that we are dealing with assignments only and not allocations too.

    3.0 Proposal

    CPM 9.0 to be modified as follows:

    9.0 Temporary Resource Assignments

    9.1 Documenting the temporary activity

    The activity requiring temporary IP resources should be publicly documented and available on a website reachable at least during the entire period of the event. Entities requiring such IP resources are expected to demonstrate an understanding that when the activity or experiment for which they require the IP resources ends, the IP resources will be returned to AFRINIC. A "publicly accessible document" is a document that is publicly and openly available free of charge and free of any constraints of disclosure. AFRINIC will not recognize any activity under this policy if such an activity cannot be publicly disclosed.

[Jordi] I think you must keep here the older text. There is a need to have historical registration data, even for temporary resources. I think this can be made easily in the AfriNIC web site, with a web page showing temporary assignments details.

    9.2 Assignments of IP resources
    Resources are assigned on a lease basis for a period of one month. The assignment can be renewed on application to AFRINIC providing the necessary information. The size of the assigned IP resource will be determined from the plan submitted by the requesting entity. In the particular case of IPv4, the size cannot exceed a /22.

[Jordi] I will say /24 or a smaller block. Regarding the period, why not just 15 days ? A conference usually is shorter than a week and you need to have a few days for the setup. If we allow AfriNIC to extend this period for special cases, which need to be justified, that's good enough.

    9.2.1 Required Documentation:
    The requesting organisation should contact AFRINIC with the following information:
    a.  Details of Organisation: Legal Organisation name, Country Where Registered, Postal Address, Physical Address, Telephone and Fax Numbers, website (this is a must).
    b.  Details of activity requiring the temporary assignment: Website detailing the activity or Website with a link to similar previous activities, Links from other (relevant) sites about this activity, and the date when the above activity ends.
    c.   The planned use of these IP resources: List subnet size required, and for what it will be used plus any AS numbers and reverse delegation, if required.
    d.  The intended date of return of the IP resources above.

    9.3 Technical recommendations
    a.  The requesting entity is encouraged to deploy IPv6-only networks and push IPv4 at the edge according to an IPv6 transition mechanism (such as NAT64+DNS64 or 464XLAT)
    b.  The requesting entity could base its architecture from some RFCs such as:
    c.  [rfc3750] (INFORMATIONAL) Unmanaged Networks for IPv6 Transition Scenarios
    d.  [rfc4213] (Standards Track) Basic Transition Mechanisms for IPv6 Hosts and Routers
    e.  [rfc6180] (INFORMATIONAL) Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment

[Jordi]  Clearly in your summary you meant "duals-stack (even using IPv4aaS, for example 464XLAT)". NAT64+DNS64 is bad. Don't suggest that, many folks don't understand consequences, and that will create troubles during the conference and you will not be able to sort out. It breaks literals and apps using old APIs.
You may want to add the following references (the first one will become, hopefully soon, an RFC):
- https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/
- https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/

A conference is not an unmanaged network, so I will not use RFC3750.

    _______________________________________________
    RPD mailing list
    RPD at afrinic.net
    https://lists.afrinic.net/mailman/listinfo/rpd

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