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

[Ca By <[e-mail]>]

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.


>
>         It breaks DNSSEC as it depends on DNS64.
>         Applications have to deal with "this connection may be NAT'd to
> IPv4"
>         which impacts on those not using 464xlat or NAT64/DNS64.
>         It requires application gateways on both ends.
>         It requires complicated code on both end.
>
> > And, i will reinterate an important point Nick made. The majority of
> > traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a
> > sliver of traffic requires 464XLAT or 4464.  Those numbers are all
> growing
> > in the right direction, more e2e v6.
> >
> >
> >
> >
> > > _______________________________________________
> > > v6ops mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v6ops
> > >
> >
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
>