<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>All interesting points of view.<br>
</p>
<p>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..</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Are not all African Exchange Points running IPv6? (Would love to
know)<br>
</p>
<div class="moz-cite-prefix">On 12/22/18 4:35 PM, Willy MANGA wrote:<br>
</div>
<blockquote type="cite"
cite="mid:07710435-7cfe-2de7-a052-2162434cd895@gmail.com">
<pre class="moz-quote-pre" wrap="">Hello Jordi,
Le 21/12/2018 à 15:50, JORDI PALET MARTINEZ via RPD a écrit :
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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. <a class="moz-txt-link-freetext" href="https://learn.afrinic.net/fr/a-propos-de-nous/where-we-ve-been">https://learn.afrinic.net/fr/a-propos-de-nous/where-we-ve-been</a>
2. same page as [1], chart below
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">[...]
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Indeed. What I mean here is : if you really really need IPv4 AND cannot
assign a public address to all resources, use NAT44.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 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).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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" ?
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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).
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">[...]
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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,.. ) ?
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
/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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">[...]
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):
- <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/">https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/</a>
- <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/">https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/</a>
A conference is not an unmanaged network, so I will not use RFC3750.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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 ...
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
RPD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Mark James ELKINS - Posix Systems - (South) Africa
<a class="moz-txt-link-abbreviated" href="mailto:mje@posix.co.za">mje@posix.co.za</a> Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: <a class="moz-txt-link-freetext" href="https://ftth.posix.co.za">https://ftth.posix.co.za</a>
</pre>
</body>
</html>