<p>It is an fortunate that this well planning that can be replicated does not consider the very individual device that has always been safe behind a non public network. </p>
<p>The decision to do this well planning remains with the ISP and what seems good to the world is what the ISP will implement and yet this, exposes the individual device to the very public vulnerability.</p>
<div class="gmail_quote">On 4 Jun 2012 13:23, &quot;Mukom Akong T.&quot; &lt;<a href="mailto:mukom.tamon@gmail.com">mukom.tamon@gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Jun 3, 2012 at 7:44 PM, Kondwani C. Hara &lt;<a href="mailto:kondwa@m-hi.org">kondwa@m-hi.org</a>&gt; wrote:<br>
&gt; While direct communication seems a good idea, direct communication exposes<br>
&gt; devices to direct attack. Where NAT existed, it was easier to limit the<br>
&gt; attacks by opening up to the public only services that are accessible to the<br>
&gt; public.<br>
<br>
<br>
Stateful packet inspection (SPI), which tends to be bundled with NAT<br>
is *not* a part of NAT (actually NAPT or PAT as few people actually do<br>
real NAT). If you really wanted it there&#39;s no reason you can&#39;t do SPI<br>
on a public IPv4 or IPv6 address.<br>
<br>
&gt;<br>
&gt; Linux or most Unix machines operating as servers, are hardened against<br>
&gt; remote attacks. Workstations are hardened against local access. Putting<br>
&gt; these on ipv6 will leave many workstations very vulnerable.<br>
<br>
Actually, a thoughtful well planned IPv6 implementation should<br>
replicate the same security policies, techniques and mechanisms you<br>
already have in place.<br>
<br>
&gt;<br>
&gt; The attacks on smartphones especially Android, seem to have been worse and<br>
&gt; difficult to manage due the little attention on security they might have<br>
&gt; received owing to the fact that its still work in progress.<br>
&gt;<br>
&gt; Exposing these to the chainability of ipv6 is really a Security disaster.<br>
<br>
<br>
&gt;<br>
&gt; That&#39;s a big bug ipv6 has.<br>
&gt;<br>
&gt; Kondwani.<br>
&gt;<br>
&gt; On 3 Jun 2012 19:34, &quot;Frank Habicht&quot; &lt;<a href="mailto:geier@geier.ne.tz">geier@geier.ne.tz</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; I understand Vint Cerf is accepting part of the blame [about limitations<br>
&gt;&gt; of v4].<br>
&gt;&gt; I believe that it&#39;s good (for innovation) to be able to have direct<br>
&gt;&gt; communication between end devices (end-to-end principle).<br>
&gt;&gt; That is gone for IPv4 (NAT), and workarounds [1] are there (none perfect).<br>
&gt;&gt;<br>
&gt;&gt; I think IPv6 will take care of it for longer that IPv4 did.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I hope we have a common understanding about history and we can go forward.<br>
&gt;&gt; How do we deploy more v6 ?<br>
&gt;&gt;<br>
&gt;&gt; I like Gert Doering&#39;s .sig :<br>
&gt;&gt; &quot;have you enabled IPv6 on something today...?&quot;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Frank<br>
&gt;&gt;<br>
&gt;&gt; PS: didn&#39;t get 2x eBGP up with Cisco 891 [2] today :<br>
&gt;&gt; clear bgp ipv6 unicast * did _not_ help<br>
&gt;&gt; reload _did_ help.     strange....<br>
&gt;&gt; Cisco IOS Software, C890 Software (C890-UNIVERSALK9-M), Version 15.1(4)M1,<br>
&gt;&gt; RELEASE SOFTWARE (fc1)<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; [1]<br>
&gt;&gt; - the one I think about are STUN etc<br>
&gt;&gt; - ipv6 over facebook, over google, don&#39;t count<br>
&gt;&gt; - 6to4 should be history, and not in discussions about the future - can we<br>
&gt;&gt; agree?<br>
&gt;&gt;<br>
&gt;&gt; [2]<br>
&gt;&gt; end-user customer, with 2 uplinks to same ISP, in AS 64512<br>
&gt;&gt; yes, i was talking about BGP over v6 and about v6<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 6/3/2012 7:52 PM, Kondwani C. Hara wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I believe by design, ipv4 was never supposed to exhaust. But as a<br>
&gt;&gt;&gt; marketing extra, even ipv6 address space will prove too little. Not<br>
&gt;&gt;&gt; every individual requires a public ip. But if every device will require<br>
&gt;&gt;&gt; a public ip, then per individual it should be expected several devices.<br>
&gt;&gt;&gt; I wonder how many ipv6 ip address are implementable? If there is an<br>
&gt;&gt;&gt; upper bound, the seemingly huge number will exhaust.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Unless we come back to the original design of ipv4 we will find that we<br>
&gt;&gt;&gt; would still encounter the same problem. We will also find that ipv4 was<br>
&gt;&gt;&gt; never supposed to exhaust in the first place.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 3 Jun 2012 14:09, &quot;Mark Tinka&quot; &lt;<a href="mailto:mark.tinka@seacom.mu">mark.tinka@seacom.mu</a><br>
&gt;&gt;&gt; &lt;mailto:<a href="mailto:mark.tinka@seacom.mu">mark.tinka@seacom.mu</a>&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    On Sunday, June 03, 2012 11:11:39 AM Mark Elkins wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;     &gt; At the end of the day - every ISP type service charges<br>
&gt;&gt;&gt;     &gt; for the IP addresses that they &#39;rent&#39; from their<br>
&gt;&gt;&gt;     &gt; Upstream or RIR. They are all businesses.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    Mark, do you mean as a hidden cost or explicitly?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    Not all ISP&#39;s charge their customers for space. But yes,<br>
&gt;&gt;&gt;    some do.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    The operations I&#39;ve run assign a minimum default for every<br>
&gt;&gt;&gt;    new turn-up. If customers want additional space for their<br>
&gt;&gt;&gt;    expansion, they only need to justify that to us (not as easy<br>
&gt;&gt;&gt;    as I&#39;m making it sound), and if they could, we&#39;d assign more<br>
&gt;&gt;&gt;    to them. Justification for additional space was always in<br>
&gt;&gt;&gt;    line with the policies enforced by the RIR in the respective<br>
&gt;&gt;&gt;    region I worked; which is fair.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    Charging for IPv4 address space isn&#39;t terribly useful, as<br>
&gt;&gt;&gt;    that&#39;s a dying resource you can&#39;t base any sustainable model<br>
&gt;&gt;&gt;    on.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    I know Product &amp; Marketing folks like to charge for IPv4<br>
&gt;&gt;&gt;    addresses as a deterrence to exhaustion, but I always tell<br>
&gt;&gt;&gt;    them that if a customer is desperate, they&#39;ll pay anything<br>
&gt;&gt;&gt;    to get it.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    Add to that, the Sales are happy making IPv4 addresses an<br>
&gt;&gt;&gt;    item line because they make more on commissions.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    So the combination of S&amp;M, in this case, is a recipe for<br>
&gt;&gt;&gt;    disaster that needs checking.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    But as a basic means of revenue when offering a service,<br>
&gt;&gt;&gt;    I&#39;ll submit it (selling IPv4 space) leaves a foul taste in<br>
&gt;&gt;&gt;    my mouth. As for IPv6, that&#39;s just immoral, but that&#39;s my<br>
&gt;&gt;&gt;    own opinion.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    Your network, your rules.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    Mark.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;    _______________________________________________<br>
&gt;&gt;&gt;    afripv6-discuss mailing list<br>
&gt;&gt;&gt;    <a href="mailto:afripv6-discuss@afrinic.net">afripv6-discuss@afrinic.net</a> &lt;mailto:<a href="mailto:afripv6-discuss@afrinic.net">afripv6-discuss@afrinic.net</a>&gt;<br>
&gt;&gt;&gt;    <a href="https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; afripv6-discuss mailing list<br>
&gt;&gt;&gt; <a href="mailto:afripv6-discuss@afrinic.net">afripv6-discuss@afrinic.net</a><br>
&gt;&gt;&gt; <a href="https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; afripv6-discuss mailing list<br>
&gt;&gt; <a href="mailto:afripv6-discuss@afrinic.net">afripv6-discuss@afrinic.net</a><br>
&gt;&gt; <a href="https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; afripv6-discuss mailing list<br>
&gt; <a href="mailto:afripv6-discuss@afrinic.net">afripv6-discuss@afrinic.net</a><br>
&gt; <a href="https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss</a><br>
&gt;<br>
<br>
<br>
<br>
--<br>
Mukom Akong [Tamon]<br>
______________<br>
<br>
“We don&#39;t LIVE in order to BREATH. Similarly WORKING in order to make<br>
MONEY puts us on a one way street to irrelevance.“<br>
<br>
<br>
[In Search of Excellence &amp; Perfection] - <a href="http://perfexcellence.org" target="_blank">http://perfexcellence.org</a><br>
[Moments of TechXcellence] - <a href="http://techexcellence.net" target="_blank">http://techexcellence.net</a><br>
[ICT Business Integration] - <a href="http://ibiztech.wordpress.com" target="_blank">http://ibiztech.wordpress.com</a><br>
[About Me] - <a href="http://about.me/perfexcellence" target="_blank">http://about.me/perfexcellence</a><br>
_______________________________________________<br>
afripv6-discuss mailing list<br>
<a href="mailto:afripv6-discuss@afrinic.net">afripv6-discuss@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss</a><br>
</blockquote></div>