Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

[Mark Andrews <[e-mail]>]

In message <[e-mail]>
, Ca By writes:
> On Wed, Sep 27, 2017 at 5:28 PM Mark Andrews <[e-mail]> wrote:
>
> >
> > In message <
> > [e-mail]>, Ca
> > By writes:
> > >
> > > On Wed, Sep 27, 2017 at 3:43 PM Ole Troan <[e-mail]>
> wrote:
> > >
> > > > > A specific example: certain vpn clients, still in service, fail
> when
> > > > > tethered to a nat64/dns64 device. Typically, a customer is
> tethering
> > > > > their work machine to their personal handset. NAT64/DNS64 does not
> > > > > provide what the client needs and neither can the OS. Such client
> SW
> > > > > may be older but is still in service, they are not yet end of
> > support.
> > > > >
> > > > > Customers care if this breaks. So do I, this is doing harm. And
> no,
> > > > > they won't revert to their corp IT dept. They know this relates to
> > their
> > > > > provider.
> > > > > With 464xlat these usecases simply work.
> > > > > I have zero calls into customer services concerning devices with
> > > > > 464xlat.
> > > > >
> > > > > 464xlat is the reason why IPv6-only can work where the end OS is
> > > > > unknown. IPv6-only for the handset mass-market is the way to
> mitigate
> > > > > exhaustion.
> > > >
> > > > 464xlat is a mechanism to deliver IPv4 service across an IPv6
> > transport.
> > > > Yes, it mitigates exhaustion. - By sharing a single IPv4 address
> among
> > > > more and more end-users.
> > > > It's just like any other CGN, with the differences being that you
> need
> > > > CE support and you can disable IPv4 in the access network.
> > > >
> > > > MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much
> all do
> > > > the same.
> > > > The main difference is where session state is kept.
> > > >
> > > > 464XLAT or more commonly deployed 44464XLAT is the worst of any
> > > > combination. It keeps sessions state both at the CE/CLAT and the
> > > > BR/PLAT.
> > > > Building scalable stateful devices is hard and expensive. And in the
> > > > case of IPv4 sharing mechanisms unnecessary.
> > > >
> > > > Ole
> > >
> > >
> > > Ole, Mark, and James — always good to have the non-operator viewpoint.
> > > Insightful observations as always.
> > >
> > > Nick has offered the “hey we did 464xlat, it worked, no regrets” case
> > > study, also insightful.
> > >
> > > I am trying to stay out of this discussion about purity of one
> solution
> > vs
> > > the other.  I was happy to leave that discussion years ago and move on
> > > with
> > > real work.
> > >
> > > But i like helping people, so i can share some insight
> > >
> > > Slide 4 of a deck
> > >
> > >
> >
> https://www.ietf.org/proceedings/98/slides/slides-98-maprg-measuring-trend
> > > s-in-ipv6-support-tommy-pauly-00.pdf
> > >
> > > The blue area is not one of constant growth.  The lesson is that what
> > > James
> > > said does not fly with mobile subscribers that can change carriers.
> They
> > > want their “broken” apps. That said, i have it on good word that blue
> > blob
> > > is  thriving now that we added some additional control points to
> allows
> > > people to use “broken” apps.  Life is good.
> > >
> > > Another data point
> > >
> > > http://www.worldipv6launch.org/measurements/
> > >
> > > As of today in the top 25, Numbers 7, 11, 17, 18 (i think), and 20
> have
> > > deployed 464xlat.  Pretty good real world stats moving real v6 packets
> > for
> > > what Ole calls “the worst” and Mark calls “sexy”.
> >
> > I said other people think it is "sexy".  I'm with Ole, it is the worst
> > of the solutions.
>
>
> Ethernet is also the worst.
>
> Token ring is much more elegant than ethernet too.  And packet over sonet
> is much more industrial than ethernet.
>
> Yet the chaotic mess ethernet is ubiquitous.  Why?  Because people had a
> relatively good experience deploying it.

Last time I looked my using ethernet doesn't impact on your using
some other layer 2 technology.

DNS64/NAT64 impacts on those not using the technology.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]