[rpd] Proposal: Clarification on temporary resource usage

Mon Dec 24 06:45:51 UTC 2018

All interesting points of view.

Regarding temporary address space and the advocacy of IPv6, its probably
about time that AFRINIC consider running an IPv6 only network at the
bi-annual meetings - that is, no native IPv4. We have had successful
IPv6 days in the past and I personally believe we should have had them
at every meeting over the past few years - but anyway..

Doing this (running IPv6 only) and informing people in advance will give
the attendees the opportunity to perhaps make sure that they can connect
back home with IPv6 before they go to the meeting - so less surprises. 
Lets eat our own dog food and get a larger segment of our community
running IPv6. Its the future after all.

AFRINIC had a core of folk that can run and do understand IPv6. Worse
case scenario is a tunnel to the nearest IPv6 connected place. Human
nature is to generally take the easy road - which is "no change" (or
IPv4 in this context). Even if you are a small ISP with only IPv4
upstream connectivity, its pretty easy to tunnel through to people like
Hurricane Electric for full IPv6 connectivity. One can even do this
using the number resources (IPv6 Addresses and ASN) that one gets from
AFRINIC.

Are not all African Exchange Points running IPv6? (Would love to know)

On 12/22/18 4:35 PM, Willy MANGA wrote:
> 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.
>
>
>> 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 :) .
>
> 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.
>
>
> 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" ?
>
>> 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).
>
>
>> 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,.. ) ?
>
>
>>     
>>     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.
> 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.
>
>
>
>> [...]
>>     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 ...
>
>
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20181224/3405b6e4/attachment.html>