Cheap LSN/CGN/NAT444 Solution

Mon Jun 30 23:23:57 UTC 2014

In message <96782.1404135619 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes:
> --==_Exmh_1404135618_1958P
> Content-Type: text/plain; charset=us-ascii
> 
> On Mon, 30 Jun 2014 15:59:47 +1000, Skeeve Stevens said:
> 
> > I am after a LSN/CGN/NAT444 solution to put about 1000 Residential profile
> > NBN speeds (fastest 100/40) services behind.
> 
> > This solution is for v4 only, and needs to consider the profile of the
> > typical residential users.  Any pitfalls would be helpful to know - as in
> > what will and and more importantly wont work - or any work-arounds which
> > may work.
> 
> Pitfall 1:  Make sure you have enough support desk to handle calls from
> everybody who's doing something that doesn't play nice with CGN/NAT444.
> And remember that unless "screw you, find another provider" is an acceptable
> response to a customer, those calls are going to be major resource sinks to
> resolve to the customer's satisfaction...

And this is where the entire industry world wide is to blame.  CGN,
DS-Lite, NAT64 are designed as end-of-transition products not start-
of-transition products.  They are designed around getting to a
legacy IPv4 network.  CGN, DS-Lite, and NAT64 all reduce functionality
that is normally available on wired networks.

Just because there was not a fixed date, like 1/1/2000, for when it
would be too late didn't mean that there wasn't a problem coming
or that plain dual stack shouldn't have been ubiquitous before then.

As a consumer I don't want to be forced to loose functionally because
the industry as a whole was too f!@$!#!@ short sighted to do what
was best for the consumer well enough in advance so that everyone
could sort out the teething issues.  Networks work because *everybody*
can speak the same protocol.  I don't care which transport protocol
I use.  I do care if I can't continue to do something because people
were too slow to react.

> Pitfall 2: These sort of short-term solutions often end up still in
> use well after their sell-by date.  If you're planning to deploy a
> new solution in 6 months, maybe throwing resources at a short-term fix
> is counterproductive and the resources should go towards making the current
> solution hold together and deploying the long-term solution...
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org