[rpd] Proposal: Clarification on temporary resource usage

Fri Jan 11 11:50:05 UTC 2019

Hi Willy,

Sorry the late answer, too busy last weeks!

See my responses below, in-line.

Regards,
Jordi

-----Mensaje original-----
De: Willy MANGA <mangawilly at gmail.com>
Fecha: sábado, 22 de diciembre de 2018, 15:46
Para: <rpd at afrinic.net>
Asunto: Re: [rpd] Proposal: Clarification on temporary resource usage

    Hello Jordi,

    Le 21/12/2018 à 15:50, JORDI PALET MARTINEZ via RPD a écrit :
    > 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).

    I'm ok with your comment. It's the purpose of this list :).

    I do not see this proposal as something mandatory. It's more like a way
    to go with some recommandations.

I'm ok with that if it is clearly stated in the policy proposal text, but I'm not sure everybody will agree that some recommendations should be part of the text, or may be in the justification.

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

    What's the issue ? human resources ?
    If you look on this map [1], you'll notice that there are IPv6 trained
    folks in almost all african countries (4322 eng. exactly [2]) ...
    I'm sure all these guys would be more than happy if there are called to
    deploy v6 networks :) .

Trained and having the real experience are different things. I'm not saying this is the case here, but I can tell you that when I do trainings (in every continent), and some people in the room have been trained already, 99.9% of them don't have real experience and 80% of the knowledge they have about IPv6 is usually mistaken, because they keep understanding IPv6 as just "IPv6 with longer addresses", but not a different deployment model, no NAT, etc.

If I'm a conference, I will not, definitively not, employ staff that is not experienced in anything needed in that conference. Why? Because a conference network needs to be deployed in very few days (sometimes hours), and you can't risk the service at all, even if the conference is only for a single day.

    IPv6 connectivity ? I'm not sure it is so difficult to have IPv6
    upstream provider even here in Africa.

    A meeting can be a good occasion for local ISP to assess their expertise
    on a small IPv6 deployment during a short period. Of course it's not
    enough but its a golden opportunity in my humble opinion.

No, for the same reason I just mention. You can risk a small portion of an enterprise network (because it is a test-bed, or an ISP pilot, etc.), and you're doing that to gain experience, etc., you have control over the people using it, probably even their devices, but not in a temporary network for a conference.

    1. https://learn.afrinic.net/fr/a-propos-de-nous/where-we-ve-been

    2. same page as [1], chart below

    >[...]
    >     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.

    Indeed. What I mean here is : if you really really need IPv4 AND cannot
    assign a public address to all resources, use NAT44.

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

    That's why you can request IPv4 according to CPM section 9 .

    Are you ok if I reword the sentence by "The requesting entity is advised
    to use IPv6 as much as possible and use NAT44 if necessary" ?

In principle, that looks good to me.

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

    That was my real intent :) . But I know it is not yet possible. Consider
    this proposal as an incentive to provide v6 to more networks and
    applications (especially for videoconference matters).

But speaking instead about IPv6 and IPv4aaS, it is an achievable middle way.

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

    Yes.. To be more pragmatic, maybe saying that the conference LANs must
    have dual-stack can be easier to accept by the community.
    During AFRINIC meetings there is already dual-stack network.

    > [...]
    >     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.

    In this paragraph if I'm right we are talking about *the activity*
    requiring temporary IP resources and NOT the information related to the
    assignation of IP resources after approval.
    In my understanding it means you should have an up to date website where
    we can find the rationale of your event; typically what you have for a
    AFRINIC, AfNOG meeting for instance...

    Maybe do you want the CPM to require a public registry with details of
    accepted requests available on AFRINIC website (requesting entity,
    purpose, prefix size,.. ) ?

Now I understand your purpose, but I don't think is good to enforce that. There are conferences with even may have web site, may be is only for closed groups, and the information may not be publicly available. And I think this doesn't justify not providing the temporary resources. I think AfriNIC must report publicly all the history of all the temporary allocations, but not necessarily each event.

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

    /24 ? Why Not ? but I prefer to be more open and just set  an upper
    limit. /24 can be in practice the size assigned.

Not that many conferences have more than 254 participants, and if that's the case, they should use NAT, so they have 254 addresses (if we go for a /24) available for all the possible "devices" that they want to have with public addresses. Let's say, offering only smaller prefixes, is one more way to push for the dual-stack with IPv4aaS (which means real IPv6+NAT44).

    On the duration, 15 days can be too short. I remind you  that there is a
    technical preparation before the event itself to set the NOC. 2, 3 days
    at least before the opening. 30 days is acceptable in my humble opinion.
    20 days is another option if necessary.

The point is to be "somehow" restrictive, but allow the staff to evaluate special cases and agree on that. I think an AfNOG is one of those cases, but most of the conferences will be just fine with 2 weeks.

    > [...]
    >     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.

    Yes but the topology is nearly the same. The most important here is the
    application requirements involved and stages of IPv6 deployment.
    The message is : there are good source of inspiration from RFCs.

    Maybe should I just indicate RFC tagged : standards and best current
    practices which can be	 applied here ...

Maybe ;-)  

    -- 
    Willy Manga
    @ongolaboy
    https://ongola.blogspot.com/

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