<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi everyone,</p>
<p>I would like to bring this SL-bis like proposal that is being
discussed in RIPE-NCC : <br>
</p>
<p><a class="moz-txt-link-freetext" href="https://www.ripe.net/participate/policies/proposals/2017-03">https://www.ripe.net/participate/policies/proposals/2017-03</a><br>
<br>
The discussion has just started but it is interesting to see the
principles and rationales of SL-bis shared in another region with
more IPv4, more IPv6 and fewer newcomers to worry about. <br>
</p>
<p>Best regards<br>
</p>
<pre class="moz-signature" cols="72">Honest Ornella GANKPA</pre>
<div class="moz-cite-prefix">Le 29/08/2017 à 14:03, ALAIN AINA a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:4B3E5FAD-8425-415A-B2DB-989CCF0F46C0@trstech.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break:
after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break:
after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break:
after-white-space;" class="">
<div class="">Hi John,</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 19 Aug 2017, at 08:15, John Hay
<<a href="mailto:jhay@meraka.csir.co.za"
class="" moz-do-not-send="true">jhay@meraka.csir.co.za</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Hi Alain,<br class="">
<div class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On 17 August 2017
at 18:35, ALAIN AINA <span dir="ltr"
class=""><<a
href="mailto:aalain@trstech.net"
target="_blank" class=""
moz-do-not-send="true">aalain@trstech.net</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="">Hi John,</div>
<div class=""> </div>
<div class="">
<div class=""> Thanks for these
comments and questions. It is the
sort of discussions, i am trying
to attract with my recent mail
on the proposal(*) See inline...</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Maybe I should have climbed
off my lurker chair earlier. :-/</div>
<div class=""><br class="">
</div>
<div class="">Before I answer some of the
questions, I think the group should
discuss how they think the IPv4 to IPv6
transition is going to happen. While we
might not totally agree because it will
be speculation, I think it can help to
better shape policies like the soft
landing one.</div>
<div class=""><br class="">
</div>
<div class="">Let me start and if someone
wants to respond on this part, we can
split it in a separate thread?</div>
<div class=""><br class="">
</div>
<div class="">If one look at the Google
IPv6 Statistics page: <a
href="https://www.google.com/intl/en/ipv6/statistics.html"
target="_blank" class=""
moz-do-not-send="true">https://www.google.com/intl/<wbr
class="">en/ipv6/statistics.html</a></div>
<div class=""><br class="">
</div>
<div class="">If one extrapolate the
graph, 50% of Google users will be using
IPv6 to reach them in around 3 years. So
after that IPv4 is the minority
protocol.</div>
<div class=""><br class="">
</div>
<div class="">At some stage we are going
to see sites or users with only IPv6
addresses. That might put pressure on
current IPv4 only sites to add IPv6,
especially if it is a CEO that cannot
communicate with someone and he finds
out that it is because his IT guys never
implemented IPv6.</div>
<div class=""><br class="">
</div>
<div class="">So at some stage even those
that think they have lots of IPv4 space,
will implement IPv6 because they need to
communicate with IPv6 only sites or
people. This will cause the use of IPv4
to dwindle because most Operating
Systems prefer IPv6 for connections if
the destination has both.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">ISPs will see traffic
through their v6tov4 translation boxes
dwindle and if v6tov4 cloud services
appear, might prefer out sourcing that
rather than doing it themselves to keep
those last sites accessible to their
IPv6 only clients.</div>
<div class=""><br class="">
</div>
<div class="">At some stage sites will
start to switch IPv4 off on dual stack
machines and if IPv4 traffic still
warrants it, maybe just a small
translation box will be in the kept in
the corner.</div>
<div class=""><br class="">
</div>
<div class="">Already a lot of the big
sites people access are available on
IPv6, Google, Akamai (also everyone that
use them to host their data), Facebook,
CNN... Those that do not have it yet,
are busy implementing it.</div>
<div class=""><br class="">
</div>
<div class="">So all this leads me to
think that in 3-4 years and probably
earlier, it will be natural for anybody
building a new network will do it IPv6
only and have a few IPv4 addresses with
a v6tov4 translation service of some
kind to handle those few sites his users
still need to access over IPv4. Not like
now where most people first think of
IPv4 addresses and then almost as an
afterthought add IPv6.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">So that leads to the
question, how long do we have to make
IPv4 addresses last because ending up
with a big block that was never
allocated is unfair to those that could
have used it now. Burning everything
today is unfair to the new guys
requesting tomorrow. Will it be unfair
to a new guy in 5 years though?</div>
<div class=""> <br class="">
</div>
<div class="">So with that as background…</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
<div>Nice background. </div>
<div><br class="">
</div>
<div>I also like your extrapolation toward 50% of
the google users using IPv6 in around 3 years and
IPv4 minority status thereafter. The main goal has
always been to move from the predominantly
IPv4-based connectivity model to a predominantly
IPv6-based connectivity model.</div>
<div class=""><br class="">
</div>
<div>I will not argue much, as you said, doing so,
will just be adding to speculation.</div>
<div><br class="">
</div>
<div>I share your optimistic views on things here and
will just build on it.</div>
<div><br class="">
</div>
<div>- While the google global stats sound
encouraging, the growth is not uniform across
regions and countries. The per region and country
distribution is more revealing.</div>
<div><br class="">
</div>
<div><a
href="https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption"
class="" moz-do-not-send="true">https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption</a></div>
<div><br class="">
</div>
<div>- Even if IPv4 becomes minority in 3 years, it
will still be in the game and may still be
majority in some regions including ours. </div>
<div><br class="">
</div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""> <br class="">
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 14 Aug 2017, at
19:48, John Hay <<a
href="mailto:jhay@meraka.csir.co.za"
target="_blank" class=""
moz-do-not-send="true">jhay@meraka.csir.co.za</a>>
wrote:</div>
<br
class="gmail-m_1604065126668407761gmail-m_-7301121054839402356Apple-interchange-newline">
<div class="">
<div dir="ltr" class=""><br
class="">
<div class="">I prefer the
current soft landing policy,
except that I do like the
direction of section 5.4.7
(IPv6 deployment reserve) of
the -BIS proposal.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">
<div class=""><br class="">
</div>
<div class=""> SL-BIS with the max
in phase 1 to /13 instead of /18
?</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">It depends on what we want
to achieve. So it has to compliment the
rest of the policy. If the policy make
it possible for a company to get the
same size via multiple small requests,
we just cause AFRINIC staff more work
and we fragment the routing tables more,
if we force the block too small.</div>
<div class=""><br class="">
</div>
<div class="">Fair is a word that has been
used in the soft landing threads and it
is one of those words that sounds so
simple, but it is not and I think that
is in part what caused all the
"unhappiness" in the Soft Landing
related threads.
<div class=""><br class="">
</div>
<div class="">To some it is fair to deny
someone that needs it now because he
already got some, for in case someone
else comes later.</div>
<div class=""><br class="">
</div>
<div class="">To others it is fair to
give to ones that ask now because they
need it now and we do not know how
many will really come in future and
they might not even need their own
IPv4 addresses anymore.</div>
<div class=""><br class="">
</div>
<div class="">Both have a point and I
think we need to find a middle way
that feels fairly fair to both sides.
:-)</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
<div>That is the whole exercise we have been trying
to build consensus around for the past 18 months.
keep serving existing members and made provision for
new comers without creating an unused space for a
long period.</div>
<div><br class="">
</div>
<div>The current SL adopted gradual exhaustion :</div>
<div>Phase 1, move from /10 to /13. no limit on
number of requests.</div>
<div>Phase 2, set max to /22, no limit on number of
requests</div>
<div>set a /12 for unforeseen future for board to
decide on when pool is empty</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div>current stats show:</div>
<div><br class="">
</div>
<div>- 87% of the afrinic membership are <= small
( >=/18 - < /16). which led to all the
proposals to fix phase 1: max to /18 or /17 or /16
instead of /13</div>
<div><br class="">
</div>
<div>- the minimum allocation size is /22 and the last
6 years stats show that /22 is the biggest
allocation per prefix distribution. </div>
<div><br class="">
</div>
<div>SL-bis 4.0 after long series of discussions
proposes:</div>
<div><br class="">
</div>
<div>
<div>Phase 1, move from /10 to /18. no limit on
number of requests.</div>
<div>Phase 2, set max to /22, no limit on number
of requests</div>
<div>Turn the unforeseen future reserve of /12 to
IPv6 deployment dedicated reserve:</div>
<div><br class="">
</div>
<div>* serve old and new members to allow access to
legacy v4-only networks from v6-only networks</div>
<div>* with the special and restrictive allocation
criteria set in 5.4.7</div>
</div>
<div><br class="">
</div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">
<div class=""><br class="">
</div>
</div>
<div class="">Maybe the fairness should be
that for the duration of phase 1,
anybody that requests, and meet the
criteria can get IPv4 space. If we
really want to, we can use -BIS 5.4.4,
where you show your planning for the
next 8 months and you get what you will
need for those 8 months. But then you
must be able to come back and request
again at the end of that period. This is
fair because someone cannot just hog all
space in the beginning, so right up to
the end newcomers also have a chance to
get space. Remember big guys connecting
many people to the internet, are not our
enemy. They do what we all think should
happen in Africa, they connect people to
the internet. Content providers should
also be able to get IPv4 addresses
because the only reason they need IPv4
addresses is because you have not
implemented IPv6 for your users yet. :-)
And they need to put their servers close
because that makes your users happy with
you. :-)<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">I think the phase 2 and
"IPv6 deployment reserve" blocks
should be folded in a single smallish
block, that is kept for only new
requests and for some really critical
invention. I don't think even DNS
should be classified as critical. New
requests get a single /24. AFRINIC
gets about 150 new members a year, so
calculations should be based around
that.<br class="">
</div>
<div class=""><br class="">
</div>
It is also fair to newcomers because
even if they come after we have run out
of the big (phase 1) block, they will
get a /24. If they arrive before we run
out, they can get a bigger block, like
the rest.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
<div>i see your points…. but</div>
<div> </div>
<div>The reserve is for people running v6-only and
need some v4 for v4overv6 using v4 sharing. New
comers will meet the criteria at 1st request which
is the main goal. At the same time, not to deny old
members who can justify that any other allocation
can meet the need. </div>
<div><br class="">
</div>
<div>Again not to deny legitimate needs and avoid
pushing old members to become new member through
artifices ? </div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><br class="">
</div>
<div class="">If we think people found
ways to receive IPv4 address space and
use it for uses that are detrimental to
the growth of internet in Africa, we
should fix the eligibility criteria or
maybe if it is possible, add a clause to
say for which kinds of use the address
space may be allocated. <br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
<div>….and make sure we can review compliance… </div>
<div><br class="">
</div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""> <br class="">
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="">
<div class="">
<div class=""><br class="">
</div>
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class=""> I would take it
a step further to say that
only new <span
class="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-"
id="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-:9sf.21">LIRs</span>
and End Users can get
assignments from it. Maybe
even only new <span
class="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-"
id="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-:9sf.22">LIRs</span>?<br
class="">
</div>
<div class=""><br class="">
</div>
<div class="">Keeping a /12
for that might be too big.
Looking at <span
class="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-"
id="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-:9sf.23">AFRINIC</span>
statistics, there are about
150 new members a year, so
for 10 years (which I think
is too long, but a nice
round number), 1500, rounded
up to 2048 at a /24 each is
a /13 that needs to be kept
out.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">The spirit of the
current SL which SL-bis followed
is to make fair distribution, give
chance to many, at all stages, but
avoid stocking unused space.</div>
<div class=""><br class="">
</div>
<div class="">Thus, the no limit on
numbers of request from members in
Phase 1 and Phase 2.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">But 5.4.6.2 in -BIS does
limit it?</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
As i said 5.4.6.2 was introduced in SL-bis 5.0 as a
compromise to a community “approved” version which
was supposed to reach consensus and be fast tracked.</div>
<div><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""> <br class="">
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">The same spirit
prevails with the dedicated
reserve for IPv6 deployment:</div>
<div class=""><br class="">
</div>
<div class="">- Covers new comers as
well as old players(LIRs and
End-users) if they meet
5.4.7.2.2. </div>
<div class=""><br class="">
</div>
<div class="">=====</div>
<div class="">5.4.7.2.2 The
applicant must demonstrate that no
other allocations or assignments
will meet this need.</div>
<div class="">=======</div>
<div class=""><br class="">
</div>
<div class="">- Make the reserve to
last for some times with :</div>
<div class=""><br class="">
</div>
<div class="">* Reserve size (/12)</div>
<div class="">* Limit the max
allocation to /24 with an
allocations/assignment window of
6 months(so a member can only get
a max of /23 in 12 months)</div>
</div>
</div>
</blockquote>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">a /12 represents a
total of 1,048,576 IPs. At a rate
of 100 nodes sharing one public
IPv4, this IPv6 dedicated reserve
allows about 104,857,600 nodes
access to legacy v4-only networks
through IPv6-only networks, when
no more v4 space is left in
AFRINIC normal pool.</div>
<div class=""><br class="">
</div>
<div class="">Africa has the lowest
Internet penetration and the
biggest growth rate (2000-2017) <a
href="http://www.internetworldstats.com/stats.htm" target="_blank"
class="" moz-do-not-send="true">http://www.internetworldstats.<wbr
class="">com/stats.htm</a></div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">True and there is no denying
that. But it also does not say future
growth has to be in IPv4 internet. </div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
<div>Definitely not. I read this as : We have a huge
users to be connected in this region, which must be
around v6, but we have to guarantee access to legacy
v4-only for a long period as probability is high
for persistent v4-only for extended period in this
region.</div>
<div><br class="">
</div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">I think anybody building a
new network now and not building it with
IPv6 from the ground up and just adding
IPv4 where needed, is wasting time and
money. The point of internet is to
communicate and get data/information
from the rest of the world, so you have
to do what the rest of the world is
doing, not what they did 5 years ago.<br
class="">
</div>
<div class=""><br class="">
</div>
<div class="">While a 100 nodes sharing an
IPv4 address might be needed now, if you
have rolled out IPv6 and get decent IPv6
connectivity, you might soon find out
that you can make the ratio higher. (For
our group of about 300 people with
dual-stacked machines, only half of our
internet traffic is IPv4 these days.)</div>
<div class=""><br class="">
</div>
<div class="">PS. I would put a question
mark around their statistics because
they are clearly behind the times with
their web site not reachable via IPv6.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
:-)</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""> <br class="">
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="">
<div class=""><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
<div class="">I do not like
5.4.6.2 in the -BIS
proposal, because it
penalise legitimate big
members, just because they
are big. (And big members
are not less efficient with
addresses.) Telling a member
you can get 8 months worth
of addresses every 24 months
is not going to fit in their
business plan. It will be
almost the same as telling
them come once only.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">5.4.6 was introduced
in SL-BIS 5.0 based on a community
request to fill a gap conditions
in SL-bis 4.0</div>
<div class=""><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
<div class="">It feels like
this part was done to
achieve a hidden agenda.
That might be better done by
updating the eligibility
criteria.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">
<div class=""><br class="">
</div>
<div class="">The motivations for
the 5.4.6.2 shall be read in the
SL-SD proposal. <a
href="https://afrinic.net/fr/library/policies/2089-soft-landing-sd"
target="_blank" class=""
moz-do-not-send="true">https://afrinic.net/fr/library<wbr
class="">/policies/2089-soft-landing-sd</a></div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I have read that, but miss
the reasoning behind it. I just see:</div>
<div class=""><br class="">
</div>
<div class=""> <i class="">"b. Allows
organizations to request
allocations/assignments without
limiting the number of times or
maximum size that can be requested.
The authors of this policy feel this
is not prudent management of the last
/8 block.”</i></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
There are more authoritative voices to elaborate on
this.</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div>In conclusion,</div>
<div><br class="">
</div>
<div>As to decide today taking into account:</div>
<div>- all we discuss here</div>
<div>- the statistics for the region</div>
<div>- the upcoming implementation of Intra-region v4
transfer</div>
<div>- the specificities of this region,</div>
<div><br class="">
</div>
<div> wise risks management strategy would recommend
the “conservative” approach which counts v4 in our v6
future for the coming years. Better be proven wrong
in this mode than in the others ? </div>
<div><br class="">
</div>
<div><br class="">
</div>
<div>Merci</div>
<div><br class="">
</div>
<div>—Alain</div>
<div>=======<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">
<div class=""><br class="">
</div>
</div>
<div class="">Regards</div>
<div class=""><br class="">
</div>
<div class="">John</div>
<div class="">--</div>
<div class="">John Hay</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<br class="">
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<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>
<br>
<br /> <table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 18px;"><a href="https://www.avast.com/fr-fr/c-malware?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclients&utm_term=oa-2335-v2-c" target="_blank"><img src="https://ipmcdn.avast.com/images/2016/icons/icon-envelope-tick-round-orange_184x116-v1.png" width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 17px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Vérification des <a href="https://www.avast.com/fr-fr/c-malware?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclients&utm_term=oa-2335-v2-c" target="_blank" style="color: #4453ea;">malwares</a> effectuée </td>
</tr>
</table>
</body>
</html>