[rpd] Proposal: Clarification on temporary resource usage

[Willy MANGA]

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



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20181222/cbc300c4/attachment-0001.sig>