Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Re: Factors affecting in-region utilization - way forward?

Andrew Alston Andrew.Alston at liquidtelecom.com
Mon Jul 21 08:59:34 UTC 2014


As an interesting note,

When I requested the removal of NAT from an internal office network, it wasn’t the management that resisted so much as the technical staff and the IT department.  The question about security was brought up over and over again, as well as the amount of work to migrate away from RFC1918 space.

Eventually the problem was solved by stating this wasn’t a request anymore, get it done.   Not an ideal approach but sometimes it’s the only way to get things done.  But what this highlights is the fact that you need management buy in sometimes to overcome stubborn resistance from technical people to the same.

Sad but true.

Andrew

From: rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] On Behalf Of Mukom Akong T.
Sent: Monday, July 21, 2014 11:44 AM
To: Seun Ojedeji
Cc: Guy Antony Halse; rpd List
Subject: Re: [rpd] Re: Factors affecting in-region utilization - way forward?


On Mon, Jul 21, 2014 at 11:42 AM, Seun Ojedeji <seun.ojedeji at gmail.com<mailto:seun.ojedeji at gmail.com>> wrote:
Below is the order that is experienced
1) We don't think its necessary to change - Infact this is mostly the case and when ICT directorate of an institution don't think there is any benefit/need to run native v4 every other item below get stalled!


[Counter]

a) So long as we are using NAT, the more users we worse performance will get. Show the IT director graphs that show that even though Internet is slow, we are still within our bandwidth usage. (The pain here which they feel is poor performance. Yes I've used this before ...successfully)

b) Let's start with the network engineers, eliminate NATs internally! Route your RFC1918 space to and NAPT at the the edge. This has two implications

    * You get visibility into your own internal nework
    * You make it easier to see that NAT is the bottleneck because your NAT kludge is not distributed everywhere on the network.

c) It should be easy to make the case for a larger block of public IPv4 space for services. (and hint, if you work on some cool internal services that the management and users love but suddenly can't use them when they are not in the office on campus, then you have one more reason to justify what that service should be on a public IP address.)


2) We understand the need to change but scare of security implications


[Counter] "What security implications are those?". Education is the first weapon against fear. "Look your fear in the eye and it will lose its power over you"

a) User behavior (clicking strange links, visiting hostile sites etc) already by-pass whateve security they think NAT provides.

b) SPI whence from the perceived benefits of NAPT come from isn't an inherent part of NAPT - it just happens to be often co-exist with a NAPT service. If for some reason you really want to do that with a public IP address, it is possible to do.



3) Our ISP is hindering our change due to extra recurring charges


Specify your requirements that will work for you in your new RFP and put your ISP on notice. Only in rare cases does an institution not have options in ISP for a whole 3 years


4) Our management may not approve extra cost of internet (its not something to feel and touch like classrooms :))


Most universities actually do highly value ICT as an investment to better the institution. The question is that does the ICT Director and his team know what the elements of effective ICTs are? So long as ICT infrastructure becomes another word for "Internet access" on campus, then of course while there is some Internet ... there's no need to improve.

Effective ICTs for the service of education is quite a lot about putting in place infrastructure that helps students, staff and administration both on-campus and off campus. These services should be available on campus but also when people move off campus. Things like

- MOOC or e-Learning services hosted on campus but that can be accessed off campus
- Online registrations systems
- Transcript application services
- Time-tables
- etc etc


I have a philosphy that one uses responsibility to buy freedom and credibility. I doubt that there's a university where the network and sys admin team have worked hard to put in place a routed internal RFC1918 network with useful services and still fail to make the case of a large block of public space. If there are, I'm offering to help guide them how to make the case to their suits.

And no, a simple request to management of let's get public IPv4 space for every user will most likely get ignored and ridiculed because of the mere size. If the top 10 universities on this continent decided to give each network user 1 public IP address, your favourite RIR's v4 space won't last a year.




--

Mukom Akong T.

http://about.me/perfexcellence |  twitter: @perfexcellent
------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------

________________________________
DISCLAIMER: This email contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient, you must not use, disclose, copy, print, or rely on this email. We cannot accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of this company or one of its agents.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20140721/58cd9d4d/attachment.html>


More information about the RPD mailing list